GitLab Acceleration Initiative meeting on 3 Apr, 2024
>>> [!note] Migrated issue
<!-- Drupal.org comment -->
<!-- Migrated from issue #3437939. -->
Reported by: [hestenet](https://www.drupal.org/user/54034)
>>>
<p>This meeting:<br>
➤ Is for core developers, initiative contributors, the Drupal Association and anyone interested in the initiative.<br>
➤ Usually happens every other Wednesday at 11:00 PT / Thursday 18:00 UTC<br>
➤ Is done over chat.<br>
➤ Happens in threads, which you can follow to be notified of new replies even if you don’t comment in the thread. You may also join the meeting later and participate asynchronously!<br>
➤ 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>
➤ Has a public agenda anyone can add to in the issue<br>
➤ *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>
<p>:zero: Who is here today? Comment in the thread below to introduce yourself!</p>
<p>:one: 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.</p>
<h2>0️⃣ Who is here today? Comment in the thread below to introduce yourself!</h2>
<table>
<tr>
<td>hestenet (he/him)</td>
<td>Tim from the DA :wave::skin-tone-3:</td>
</tr>
<tr>
<td>tyler36</td>
<td>Hi from Japan :wave:</td>
</tr>
</table>
<h2>1️⃣ 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>
<tr>
<td>cmlara</td>
<td>For discussion:Consider migrating packaging to GitLab (still have D.O. store the packages and not allow replacement of published releases) allowing maintainers to perform more complex build process for releases (such as compile style sheets at build time instead of checking in compiled style sheets, build rendered HTML/PDF manuals instead of markdown manuals, etc)</td>
</tr>
<tr>
<td>tyler36</td>
<td>For discussion:Drupal has embraced DDEV for local development. I am aware of <a href="https://github.com/ddev/github-action-setup-ddev">https://github.com/ddev/github-action-setup-ddev</a> which setups a DDEV environment in Github CI for running linting/tests against. It works well because its the same self-contained version of the site that runs locally (PHP, database etc.). I would like to replicate this process in Gitlab CI.I started a thread that shows interest, but no solution. Not sure if it's even do-able because I lack knowledge on Gitlab runners and Drupal's Gitlab implementation.</td>
</tr>
</table>
<h2>2️⃣ GitLab Issues updates</h2>
<table>
</table>
<h2>2️⃣ 1️⃣ SSO deployment update.We've been troubleshooting with our hosted keyclocak provider because our user database is so large some of their automated features weren't quite working.Right now I think we're hopeful to resolve those last things and kick off the dev migration any day now.</h2>
<table>
</table>
<h2>2️⃣ 2️⃣ Moshe raised this issue for a project migration back to our internal gitlab - as a candidate for early gitlab issues:<a href="https://drupal.slack.com/archives/CGKLP028K/p1711554552440619">https://drupal.slack.com/archives/CGKLP028K/p1711554552440619</a></h2>
<table>
<tr>
<td>hestenet (he/him)</td>
<td>I'll be honest that I haven't had much time to look at this @moshe between presenting virtually in Burkina Faso over the weekend and a lot of other things going on.</td>
</tr>
<p>INCOMPLETE</p>
<h2>3️⃣ GitLab CI updates</h2>
<table>
</table>
<h2>3️⃣ 1️⃣ Maintainer notification that DrupalCI will be disabled in July has been sent, asking all maintainers to convert to GitLab CI. Last I heard there were still 2000+ projects on Drupal CI - and GitLabCI projects had been catching up.<a href="https://drupal.slack.com/archives/CGKLP028K/p1712162525803099">https://drupal.slack.com/archives/CGKLP028K/p1712162525803099</a></h2>
<table>
<tr>
<td>fjgarlin</td>
<td>Do we have a number of projects using GitLab CI currently? I think @drumm got that number somewhere. I’m starting to prepare slides for DCON and it would be good info (even if it changes from now to a month’s time)</td>
</tr>
<tr>
<td>drumm</td>
<td>5,137 schedules for 2,721 projectsMariaDB [drupal]> SELECT count(1), count(DISTINCT pcp.nid) FROM pift_ci_project pcp INNER JOIN pift_ci_label_map pclm ON pclm.machine_label = pcp.core_branch AND pclm.status = 1 INNER JOIN field_data_field_release_category fdf_rc_p ON fdf_rc_p.entity_id = pcp.release_nid INNER JOIN field_data_field_release_category fdf_rc_cb ON fdf_rc_cb.entity_id = pcp.release_nid AND fdf_rc_cb.field_release_category_value = fdf_rc_p.field_release_category_value WHERE pcp.testing != 'disabled';<br>
+----------+-------------------------+<br>
| count(1) | count(DISTINCT pcp.nid) |<br>
+----------+-------------------------+<br>
| 5137 | 2721 |<br>
+----------+-------------------------+</td>
</tr>
<tr>
<td>fjgarlin</td>
<td>That’s drupalci projects right? Do we have number of projects using gitlab ci?</td>
</tr>
<tr>
<td>drumm</td>
<td>Right, 1,472 have GitLab CI <a href="https://git.drupalcode.org/search?group_id=2&scope=blobs&search=filename%3A.gitlab-ci.yml">https://git.drupalcode.org/search?group_id=2&scope=blobs&search=filename%3A.gitlab-ci.yml</a></td>
</tr>
<tr>
<td>Jonathan1055</td>
<td>Those numbers have dropped from what you said back in January."3,455 modules had drupalci testing in Oct 2023. By Jan 2024 1,713 had used Gitlab"I made a note of it, will try to find where it came from. So are we saying 1713 - 1472 = 241 projects have been deleted from Gitlab?</td>
</tr>
<tr>
<td>fjgarlin</td>
<td>I thought the same when I saw the number. It comes from here:<span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/drupalci/issues/3412417" title="Status: Closed (fixed)">#3412417: Disable DrupalCI testing</a></span>#comment-15410492</td>
</tr>
<p>INCOMPLETE</p>
<h2>3️⃣ 2️⃣ There is a proposal for a TWIG linter CI job - thanks to @Steffen Schlae[#3437838]</h2>
<table>
</table>
<h2>3️⃣ 3️⃣ There is an idea for validation of translatable strings:<a href="https://drupal.slack.com/archives/CGKLP028K/p1712081707946159This">https://drupal.slack.com/archives/CGKLP028K/p1712081707946159This</a> still probably needs an issue opened (cc @jurgenhaas)</h2>
<table>
<tr>
<td>jurgenhaas</td>
<td>Yes, I'll be opening an issue for it, just wanted to hear the water on how this would be seen by others, or to see of something had already been addressed elsewhere.</td>
</tr>
<tr>
<td>hestenet (he/him)</td>
<td>++</td>
</tr>
<tr>
<td>jurgenhaas</td>
<td>Here is the issue for it:<span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/gitlab_templates/-/issues/3438859" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/gitlab_templates/-/issues/3438859</a></span></td>
</tr>
</table>
<h2>4️⃣ Per @cmlaraFor discussion:Consider migrating packaging to GitLab (still have D.O. store the packages and not allow replacement of published releases) allowing maintainers to perform more complex build process for releases (such as compile style sheets at build time instead of checking in compiled style sheets, build rendered HTML/PDF manuals instead of markdown manuals, etc)</h2>
<table>
<tr>
<td>hestenet (he/him)</td>
<td>My first concern is the way the packaging/signing process will work with the packaging pipeline for autoupdates. Right now that's based on the assumption of centralized packaging.</td>
</tr>
<tr>
<td>drumm</td>
<td>My first concern is version number formatting</td>
</tr>
<tr>
<td>hestenet (he/him)</td>
<td>Ooooh yes.</td>
</tr>
<tr>
<td>ctrladel</td>
<td>General :plus_one: from me. Probably more of a module maintainers problem but how would dev versions work with a gitlab release artifact. To use dev versions sites would need to individually build each contrib module taking this approach.</td>
</tr>
<tr>
<td>cmlara</td>
<td>Initial thoughts from me:This would require a D.O. API endpoint (so delayed to D10 upgrade) to trigger D.O. to mirror the release and do anything it needs to do (sounds like signing would be one item I forgot about). For signing I believe we could transfer calculated release binary checksum as part of the process so that the sign server knows they were not modified in transit.Package file and triggering a remote API could be helped with a default gitlab_template build process that performs the normal build routine (adds the date timestamp and other info into the info.yml, calls the D.O. api, etc) more advanced users could override however corrupt releases would be their responsibility.Recent Linux community issues do bring up the point that a different build vs source can hide flaws that our current source only method makes harder to implement. I don't really think that is a no-go reason, though since it requires maintainer compromise</td>
</tr>
<p>INCOMPLETE</p>
<p>Participants:</p>
<p>hestenet, tyler36, cmlara, fjgarlin, drumm, Jonathan1055, jurgenhaas, ctrladel, moshe</p>
<p>Meeting link: <a href="https://drupal.slack.com/archives/CGKLP028K/p1712167303578999">https://drupal.slack.com/archives/CGKLP028K/p1712167303578999</a></p>
</table></table></table>
issue