>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3352480. --> 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>hestenet (he/him)</td> <td>Tim from the DA, kicking off threads</td> </tr> <tr> <td>markdorison</td> <td>Mark from Chromatic. Hi! :blob_wave:</td> </tr> <tr> <td>tyler36</td> <td>Hi!</td> </tr> <tr> <td>irinaz</td> <td>Hi, checkin in late</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> <tr> <td>moshe</td> <td>Any chance we can open up personal tokens to everyone or to trusted users (if trust is the holdup)? The glab cli tool is dead on our gitlab instance without a token. Among many other use cases for a token.</td> </tr> <tr> <td>moshe</td> <td>How can we quickly release gitlab issues for projects that want them? Maybe they forego an issue migration. And maybe their pair repo in &ldquo;community forks&rdquo; gets setup by hand. Or contributors use personal forks until something better comes along. My perception is that we are always waiting on improvements from Gitlab. It&rsquo;s been 3 years since drupalspoons launched. Im hoping we can move to gitlab based on what they offer today.</td> </tr> <tr> <td>hestenet (he/him)</td> <td>This meeting:&#10148; Is for core developers, initiative contributors, the Drupal Association and anyone interested in the initiative.&#10148; Usually happens every other Wednesday at 11:00 PT / Thursday 06:00 UTC&#10148; Is done over chat.&#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!&#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.&#10148; Has a public agenda anyone can add to in the issue&#10148; *Transcript will be exported and posted* to the agenda issue. For anonymous comments, start with a &#128100; emoji. To take a comment or thread off the record, start with a &#128683; emoji.ping: @mixologic @FeyP @jurgenhaas (go to the issue of the next meeting to add or remove yourself from the list)</td> </tr> </table> <h2>2&#65039;&#8419; GitLabCI</h2> <table> </table> <h2>2&#65039;&#8419; 1&#65039;&#8419; Many thanks to @moshe (and @jurgenhaas) for several merge requests to the GitLab CI templates:A short summary of changes:The template.gitlab-ci.yml file has been updated: <a href="https://git.drupalcode.org/project/gitlab_templates/-/blob/1.0.x/gitlab-ci/template.gitlab-ci.ymlThis">https://git.drupalcode.org/project/gitlab_templates/-/blob/1.0.x/gitlab-ci/template.gitlab-ci.ymlThis</a> moves just about everything into an include file, so if you use this template, you should automatically receive future improvements to testing. Dependency on DrupalSpoons composer plugin has been removed, and necessary parts incorporated directlyNightwatch testing has been added. It also now triggers a merge train to test itself against a real project, in this case keycdn. (edited)</h2> <table> <tr> <td>hestenet (he/him)</td> <td>@moshe anything in particular you want to highlight to folks using this?</td> </tr> <tr> <td>moshe</td> <td>This is the ci system I&rsquo;ve always wanted :). Hope folks will give it a try and report positive or constructive feedback.</td> </tr> </table> <h2>2&#65039;&#8419; 2&#65039;&#8419; Outstanding issue #1:There is some artifact handling that we could use an MR to sort out: <a href="https://git.drupalcode.org/project/keycdn/-/pipelines/10853/failures ">https://git.drupalcode.org/project/keycdn/-/pipelines/10853/failures </a>(edited)&nbsp;</h2> <table> </table> <h2>2&#65039;&#8419; 3&#65039;&#8419; Outstanding issue #2:@larowlan is still seeking help to resolve performance/timeout issues with core tests on our GitLab runners:<a href="https://git.drupalcode.org/project/gitlab_ci_testbed_for_drupal_core/-/jobs/40970">https://git.drupalcode.org/project/gitlab_ci_testbed_for_drupal_core/-/jobs/40970</a>(Although it may also be worth updating your gitlab-ci.yml to the latest version above, and and reimplementing any overrides as needed as well).&nbsp;(edited)&nbsp;</h2> <table> <tr> <td>hestenet (he/him)</td> <td>We have some ideas from last meeting here: <a href="https://drupal.slack.com/archives/CGKLP028K/p1680799908391609">https://drupal.slack.com/archives/CGKLP028K/p1680799908391609</a></td> </tr> <tr> <td>moshe</td> <td>I borrowed a couple ideas from that MR so kudos to its authors.</td> </tr> </table> <h2>2&#65039;&#8419; 4&#65039;&#8419; Outstanding issue #3: We still need to get D7 testing working properly - the new idea @moshe introduced of 'skip variables' should help with this (or we can use a whole separate template file for people to use in 7.x branches)&nbsp;(edited)&nbsp;</h2> <table> <tr> <td>cmlara</td> <td>With D7 slated slated to go EOL in November is there an argument for just skiping working on D7 support and have them stay on DrupalCi?&nbsp; DrupalCi might be around that long for Core&nbsp; anyways as they are slated to be the last group to convert.</td> </tr> <tr> <td>hestenet (he/him)</td> <td>That could happen purely by default - however, there are contrib projects that still test against d7, so it affects their migration as well..</td> </tr> <tr> <td>cmlara</td> <td>Guess it depends a bit on if DO issues are going away before November as well?&nbsp; As it currently stands it looks like a project can use DrupalCi and GitlabCi. Was thinking a project could have both, keep DrupalCi for the 7.x and GitlabCi for the new....&nbsp; Maybe a little more confusion for users though.</td> </tr> </table> <h2>3&#65039;&#8419; Credit systemD9/10 code for this exists in a dev environment - is waiting in line with the D9/10 upgrade work we have going for project browser - as well as the SSO deployment </h2> <table> </table> <h2>4&#65039;&#8419; Issue workflow@fjgarlin is going to be able to pivot to help look at the issue collaboration workflow and permissions in the coming weeksGitLab is making several improvements as they experiment with 'community forks' that will benefit us directly: <a href="https://gitlab.com/gitlab-community/meta#gitlab-community-forks">https://gitlab.com/gitlab-community/meta#gitlab-community-forks</a></h2> <table> <tr> <td>hestenet (he/him)</td> <td>Per @mosheHow can we quickly release gitlab issues for projects that want them? Maybe they forego an issue migration. And maybe their pair repo in &ldquo;community forks&rdquo; gets setup by hand. Or contributors use personal forks until something better comes along. My perception is that we are always waiting on improvements from Gitlab. It&rsquo;s been 3 years since drupalspoons launched. Im hoping we can move to gitlab based on what they offer today.</td> </tr> <tr> <td>hestenet (he/him)</td> <td>FWIW - I don't think we're necessarily blocked on the next GitLab improvements, that's more a note that they are things we'll want to incorporate when available.</td> </tr> <tr> <td>hestenet (he/him)</td> <td>The revision to the plan outlined here: [#3250923]Is to use an integration similar to what @fjgarlin has built for credits - having a bot post to issues/MRs to provide a link to get access to that fork for collaboration.And then we do need the issue migration tools.</td> </tr> <tr> <td>hestenet (he/him)</td> <td>I'm worried about the mess of not migrating existing issues at first and then having to rationalize a d.o queue against a gitlab queue for specific projects.</td> </tr> <tr> <td>fjgarlin</td> <td>I think the biggest issue is a actually the contribution records new system. Projects on gitlab now wouldn&rsquo;t have the ability to assign credits.</td> </tr> <tr> <td>fjgarlin</td> <td>Until the new system is up and running that is</td> </tr> <tr> <td>hestenet (he/him)</td> <td>But the code for that is mostly written (thanks to you, heh) - so in terms of the additional outstanding items before all of those things can coordinate to go forward together.</td> </tr> <tr> <td>hestenet (he/him)</td> <td>But yes, worth thinking about how we do a first 'opt in' of issues for select projects, as we have done with ci.</td> </tr> <tr> <td>moshe</td> <td>IMO, a "bias for action" mentality can break down these barriers.Alpha projects dont get contribution recordsAlpha projects either get issue migration (if easy), or they agree to never get an issue migration.</td> </tr> <tr> <td>hestenet (he/him)</td> <td>Hmm.&nbsp; It's not my favorite idea, but I get where you're coming from...</td> </tr> <tr> <td>fjgarlin</td> <td>The issue migration was designed to be run per project so it&rsquo;d be easy.1 might be detrimental to people wanting to help in the project that also care about the credits, but it&rsquo;s a way forward</td> </tr> <tr> <td>moshe</td> <td>1 might be detrimental to people wanting to help in the project that also care about the credits, but it&rsquo;s a way forward"Bias for action" dilemmas always have unwanted side effects. Without those there is no need for a discussion.</td> </tr> <tr> <td>markdorison</td> <td>How can we quickly release gitlab issues for projects that want them?I&rsquo;m worried about the mess of not migrating existing issues at first and then having to rationalize a d.o queue against a gitlab queue for specific projects.What if it began as an option only for newly created projects?&nbsp;(edited)</td> </tr> </table> <h2>5&#65039;&#8419; Possibility of opening up Personal tokens, at minimum for select users, if not for everyone.</h2> <table> <tr> <td>hestenet (he/him)</td> <td>Per @moshe</td> </tr> <tr> <td>hestenet (he/him)</td> <td>I need to see if the way we block certain admin pages would allow us to do it on a per user basis..</td> </tr> <tr> <td>cmlara</td> <td>Is there a reason not to open it up to all?</td> </tr> <tr> <td>hestenet (he/him)</td> <td>The biggest concern is if using the token + api access exposes some configuration options that we currently have deliberately blocked off by redirecting away from those paths in the ui&nbsp;(edited)</td> </tr> <tr> <td>cmlara</td> <td>And linking the related open issue that could use an update (and so @moshe can follow)<span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/drupalorg/-/work_items/3199831" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/drupalorg/-/work_items/3199831</a></span></td> </tr> <tr> <td>cmlara</td> <td>Might need to look at manipulating the content at the L7 level than instead of filtering by url, or find a way to syncing changing content back if it gets modified. If we loose the ability to use tooling that could be a lot of wasted hours for developers.</td> </tr> <tr> <td>cmlara</td> <td>Extending on the above, can you think of any configuration that is currently blocked off that would cause actual damage if access is given?</td> </tr> <tr> <td>hestenet (he/him)</td> <td>Not off the top of my head, but that's part of why I need to look again. Hoping the answer is no.</td> </tr> </table>