>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3355209. --> Reported by: [hestenet](https://www.drupal.org/user/54034) >>> <h2>Transcript</h2> <h2>0&#65039;&#8419; Who is here today? Comment in the thread below to introduce yourself!</h2> <table> <tr> <td>markdorison</td> <td>Hey! Mark from Chromatic here. :fox_hello_wave:</td> </tr> <tr> <td>longwave</td> <td>:wave:</td> </tr> <tr> <td>dww</td> <td>Derek :wave:</td> </tr> <tr> <td>kimb0</td> <td>Kim :wave:</td> </tr> <tr> <td>quietone</td> <td>HI, catching up</td> </tr> <tr> <td>el7cosmos</td> <td>:wave:</td> </tr> <tr> <td>irinaz</td> <td>hi</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 CI:No promises, and I don't want to jump the gun - but right now we're feeling quite hopeful that we can enable GitLab for all projects prior to DrupalCon PittsburghDrupalCI will still be onWe'll still be making changes (but with the include templates, we can make changes without having to have everyone re-implement the temlpate) We'll still have outstanding work for core testing and d7 testing. (edited)</h2> <table> <tr> <td>markdorison</td> <td>Is there any plan to show GitLab CI test results on the issue page like we do for Drupal CI, or is the idea that since we are transitioning to GitLab issues that would be a waste of effort?</td> </tr> <tr> <td>hestenet (he/him)</td> <td>Yeah, we're not intending to invest time in integrations with the existing issue queue.</td> </tr> <tr> <td>markdorison</td> <td>Makes sense!&nbsp;(edited)</td> </tr> <tr> <td>moshe</td> <td>Would it make sense to put out a call for more alpha testers? I'm OK with going GA with what we have - I'm just asking. And also nudge our existing testers to update to the slimmed down template?</td> </tr> <tr> <td>hestenet (he/him)</td> <td>At the very least a message in the issue and an @-here in this channel is a good idea.</td> </tr> <tr> <td>moshe</td> <td>OK, I will do that. I'll wait for a merge of <a href="https://git.drupalcode.org/project/gitlab_templates/-/merge_requests/13">https://git.drupalcode.org/project/gitlab_templates/-/merge_requests/13</a> so we be a smidge more better &#128578;</td> </tr> <tr> <td>hestenet (he/him)</td> <td>Quick clarification - why include that variable in main vs in the variables include?</td> </tr> <tr> <td>moshe</td> <td>The variable only applies to phpunit so I chose to add in .phpunit-base and not .test-variables</td> </tr> <tr> <td>hestenet (he/him)</td> <td>Oh I see, it's within that scope - the 'changes' ui excerpts it out so that wasn't obvious</td> </tr> <tr> <td>hestenet (he/him)</td> <td>Alright looks good.</td> </tr> <tr> <td>hestenet (he/him)</td> <td>Merged</td> </tr> <tr> <td>hestenet (he/him)</td> <td>Re: encouraging testers - I can work on the @-here comment if you want to do the issue comment? Or I'm happy to do both, whichever works.</td> </tr> <tr> <td>hestenet (he/him)</td> <td>@moshe how does this look?@-here - &#128227; Calling all project maintainers who have been testing GitLab CI!There has been tons of progress on the .gitlab-ci.yml template, and we're getting very close to enabling GitLabCI for all projects - but we need your help!Would you please help us test the template before general release by updating your .gitlab-ci.yml file from the latest example? Here are the instructions: <a href="https://www.drupal.org/docs/develop/git/using-gitlab-to-contribute-to-drupal/gitlab-ci#s-using-the-drupal-association-gitlab-ciyml-templateIf">https://www.drupal.org/docs/develop/git/using-gitlab-to-contribute-to-drupal/gitlab-ci#s-using-the-drupal-association-gitlab-ciyml-templateIf</a> you're a project maintainer who isn't involved in testing GitLabCI yet, now is a great time to opt in. (edited)</td> </tr> <tr> <td>moshe</td> <td>looks great. thanks for doing this.</td> </tr> <tr> <td>drumm</td> <td>I&rsquo;d use the issue with requesting early CI access</td> </tr> <tr> <td>moshe</td> <td>Actually, maybe I can get eslint fixed before we ping everyone. @Jonathan1055 posted a clue. Lemme try for an hour.</td> </tr> <tr> <td>hestenet (he/him)</td> <td>Sure</td> </tr> <tr> <td>dww</td> <td><span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/infrastructure/-/work_items/3261803" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/infrastructure/-/work_items/3261803</a></span>#comment-15035094 (opt-in request for <a href="https://www.drupal.org/project/entitygroupfield">https://www.drupal.org/project/entitygroupfield</a>)</td> </tr> <tr> <td>kimb0</td> <td>As an alpha tester, I'm happy with the template. I think there is still an issue with spinning up extra services that may or may not be related to how it is configured</td> </tr> <tr> <td>moshe</td> <td>ESLint fix <a href="https://git.drupalcode.org/project/gitlab_templates/-/merge_requests/14">https://git.drupalcode.org/project/gitlab_templates/-/merge_requests/14</a> (could use a review from anyone who knows about js linting)</td> </tr> <tr> <td>hestenet (he/him)</td> <td>Reviewing as best I can now, as a non js linting expert.</td> </tr> <tr> <td>hestenet (he/him)</td> <td>Pretty sure it'll be mergable either way - just open to further improvements if said expert does come along.</td> </tr> <tr> <td>hestenet (he/him)</td> <td>@moshe Can you comment on this review thread from @Jonathan1055 <a href="https://git.drupalcode.org/project/gitlab_templates/-/merge_requests/14#note_171895">https://git.drupalcode.org/project/gitlab_templates/-/merge_requests/14#note_171895</a> ?</td> </tr> <tr> <td>moshe</td> <td>Imo we can add that as a follow up.</td> </tr> <tr> <td>hestenet (he/him)</td> <td>'k - merged.</td> </tr> <tr> <td>hestenet (he/him)</td> <td>Follow up here: <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/gitlab_templates/-/issues/3358301" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/gitlab_templates/-/issues/3358301</a></span></td> </tr> </table> <h2>3&#65039;&#8419; Implementation work is in progress on the issue workflow process (with the credit process largely built already) - Not ready to demo yet, but maybe we can share some screenshots or previews in upcoming meetings/at DrupalCon.</h2> <table> <tr> <td>moshe</td> <td>Awesome. I'm happy to help as needed.</td> </tr> <tr> <td>dww</td> <td>Curious if the new credit UI will help craft a commit message for the merge.</td> </tr> <tr> <td>dww</td> <td>Also if core committers are going to use GitLab to actually merge MRs, or if they're still going to do the patch download and local checks thing like now.</td> </tr> <tr> <td>hestenet (he/him)</td> <td>I can't answer the 2nd question - but hopefully @fjgarlin can speak to the first when online tomorrow</td> </tr> <tr> <td>dww</td> <td>Cuz a problem I'd like to help solve, but don't want to work on in legacy issue land, is letting the community help craft the right commit message (however that's going to end up in core) as the issue is developed, instead of putting it most/all on the sole committer when they're finally ready to commit/push.</td> </tr> <tr> <td>hestenet (he/him)</td> <td>That's a cool idea</td> </tr> <tr> <td>dww</td> <td>Thanks. It's been floating in various forms for a while. E.g. a dedicated section of our default issue summary template for it.GL already lets you include in the MR some metadata about how the merge commit is supposed to happen.&nbsp; We could potentially tie into / use that.</td> </tr> <tr> <td>dww</td> <td>But the core committers would have to (hopefully automatically) pull that into the local commit they can really push...</td> </tr> <tr> <td>dww</td> <td>@larowlan Can you speak to core committer plans re: local commits + checks vs. actually merging via GL UI?</td> </tr> <tr> <td>dww</td> <td>Overall, I'd rather the commit message stuff happened in the GL issue, not in each MR.</td> </tr> <tr> <td>larowlan</td> <td>we have a git commit pre hook for local commits. I still use local commits over GL merge button (or rather the d.o merge button) because generally I'm doing backports etc. I would like to think at some point we got to the point where we could just use GL</td> </tr> <tr> <td>dww</td> <td>Do you copy/paste from the d.o commit message UI as you do the local commit?</td> </tr> <tr> <td>moshe</td> <td>My .02 is that we should ditch the author preamble in the commit message convention. They actually hamper usability. Commit credit is handled separately.</td> </tr> <tr> <td>dww</td> <td>I've been trying to get us to ditch that for like 7 years now. :joy:</td> </tr> <tr> <td>dww</td> <td>$category #nid: Summary <p>CreditsE.g.:Task #2932518: Deprecate watchdog_exception</p> <p>by kim.pepper<br> joachim<br> ...or:Bug #2998451: Toolbar tray rendering can result "flickering" resizing of content area to accommodate open trays</p> <p>by ...</p></td> </tr> <tr> <td>dww</td> <td><span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-17"><a href="https://www.drupal.org/project/drupal/issues/2323715" title="Status: Closed (outdated)">#2323715: [policy, no patch] Determine format for commit credit for individuals/organizations/customers</a></span></td> </tr> <tr> <td>moshe</td> <td>kk. Not really my area of interest but I see the value. Once you have a commit hash you can lookup the MR and any associated Gitlab issues.</td> </tr> <tr> <td>dww</td> <td>Everywhere else, the Git UI is optimized for short 1-line summaries.&nbsp; Our preamble kills that.&nbsp; E.g. if you ever try to do a git rebase -i you have almost no context to work with most of the time.</td> </tr> <tr> <td>dww</td> <td>(sorry, we're getting off topic re: GL issue UI) :sweat_smile:</td> </tr> <tr> <td>larowlan</td> <td>Do you copy/paste from the d.o commit message UI as you do the local commit?Yes</td> </tr> <tr> <td>larowlan</td> <td><a href="https://git-scm.com/docs/git-commit#_discussionThough">https://git-scm.com/docs/git-commit#_discussionThough</a> not required, it&rsquo;s a good idea to begin the commit message with a single short (less than 50 character) line summarizing the change, followed by a blank line and then a more thorough description</td> </tr> <tr> <td>kimb0</td> <td>Looks like there is a convention to use Co-Authored-By: [name] &lt;[email]&gt; for multiple extra authors in the message body,</td> </tr> <tr> <td>dww</td> <td>Yeah, all this is discussed in the above issues (<span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-17"><a href="https://www.drupal.org/project/drupal/issues/2323715" title="Status: Closed (outdated)">#2323715: [policy, no patch] Determine format for commit credit for individuals/organizations/customers</a></span>)</td> </tr> <tr> <td>quietone</td> <td>FYI, the docs for the process to make a core commit</td> </tr> <tr> <td>fjgarlin</td> <td>I tried to mirror what was mostly on the current system.The commit message defaults to the issue title. We dropped the by &hellip; within the message as the credit is completely separate from the commit message. So it&rsquo;s just the author and the commit message that&rsquo;s tweaked.All that box is JS driven, taking the data from what&rsquo;s rendered on the page.</td> </tr> <tr> <td>fjgarlin</td> <td>I haven&rsquo;t seen the above mentioned issues yet, but my understanding is that the credit is driven by the credit system and that the commit message is not important (maybe it was in the past?)</td> </tr> <tr> <td>dww</td> <td>Thanks for the preview!I'm not sure we should completely drop the credits in the commit history, even if we also track them elsewhere. That seems important to discuss somewhere before we implement it.&nbsp; We should definitely split it up into multi-line as part of the change.I think we want $category #ID: $summary, e.g:Bug #3323225: Whatever we fixednot just "Whatever we fixed" as the 1st line.</td> </tr> <tr> <td>dww</td> <td>The commit history is still important for all sorts of things like git blame, etc.&nbsp; Just because we store the credits in an external system for d.o profiles + marketplace doesn't mean we don't want the info stored in Git as we always have.</td> </tr> <tr> <td>fjgarlin</td> <td>that wouldn&rsquo;t be a problem at all. the info is there so we can easily add the usernames.As for the Bug #&hellip;: &hellip;, maybe we can automate the $type #ID: part and make it part of the issue name?</td> </tr> <tr> <td>fjgarlin</td> <td>in any case, I&rsquo;ll follow along those issues and implement accordingly</td> </tr> <tr> <td>dww</td> <td>I'd rather leave the issue title the plain-text 1-line summary, and keep the other stuff in their separate fields (for the issue UI).&nbsp; We only want to glue them together when creating the commit message to copy/paste.</td> </tr> </table> <h2>4&#65039;&#8419; any update on adding ability to shell into builds and debug for certain users - blocking debug of core test run timeouts</h2> <table> <tr> <td>hestenet (he/him)</td> <td>Sorry - I don't have an update yet. Haven't had the time to dig into it myself.</td> </tr> <tr> <td>hestenet (he/him)</td> <td>If other folks out there seeing this thread want to support, I won't turn down the help &#128578;</td> </tr> <tr> <td>moshe</td> <td>There are 2 server configurations that are needed <a href="https://docs.gitlab.com/ee/ci/interactive_web_terminal/#configuration">https://docs.gitlab.com/ee/ci/interactive_web_terminal/#configuration</a></td> </tr> <tr> <td>andypost</td> <td>btw WebIDE already enabled <a href="https://git.drupalcode.org/-/ide/project/project/drupal/edit/10.1.x/-/">https://git.drupalcode.org/-/ide/project/project/drupal/edit/10.1.x/-/</a></td> </tr> <tr> <td>hestenet (he/him)</td> <td>@andypost - do you mean that interactive web terminals for webIDE are already working? If so that's a good start, although I beleive they don't provide access to runners: <a href="https://docs.gitlab.com/ee/user/project/web_ide/index.html#interactive-web-terminals-for-the-web-ide-beta">https://docs.gitlab.com/ee/user/project/web_ide/index.html#interactive-web-terminals-for-the-web-ide-beta</a></td> </tr> <tr> <td>andypost</td> <td>No, I mean webIDE enabled but not terminals</td> </tr> <tr> <td>hestenet (he/him)</td> <td>The scary thing I'm not seeing is how to restrict the interactive terminal access on a per project basis...</td> </tr> <tr> <td>hestenet (he/him)</td> <td>We do let people register their own runners, so they can control the runner config directly (but I don't know if they can enable the interactive terminal on bring-your-own runners so that might not even be a temporary solution).</td> </tr> <tr> <td>moshe</td> <td>Why does it need to be enabled on a per project basis? There is no security issue afaik - the runners are designed to host untrusted code.</td> </tr> <tr> <td>hestenet (he/him)</td> <td>Well you could already exploit a runner by committing code to run in your pipelines that mines bitcoin or whatever - so it wouldn't prevent that. But being able to do that sort of thing without even having a record of what happened in a commit log or something might make it harder to monitor and prevent, even with per project minute limits and the like.</td> </tr> <tr> <td>hestenet (he/him)</td> <td>It may not ultimately be a problem but 'give shell access to servers we're paying for' just triggers the warning bells in my brain, heh</td> </tr> <tr> <td>moshe</td> <td>Makes sense. I propose we allow by default and shut down if we cant easily manage any abusers.</td> </tr> </table>