Closed (fixed)
Project:
Drupal.org infrastructure
Component:
Meeting
Priority:
Normal
Category:
Plan
Assigned:
Issue tags:
Reporter:
Created:
27 Jul 2022 at 18:49 UTC
Updated:
21 Oct 2022 at 18:29 UTC
Jump to comment: Most recent
This meeting:
➤ Is for core developers, initiative contributors, the Drupal Association and anyone interested in the initiative.
➤ Usually happens every other Wednesday at 11:00 PT / Thursday 06:00 UTC
➤ Is done over chat.
➤ 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!
➤ 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.
➤ Has a public agenda anyone can add to in the issue
➤ *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.
ping: @mixologic @FeyP @jurgenhaas (go to the issue of the next meeting to add or remove yourself from the list)
0️⃣ Who is here today? Comment in the thread below to introduce yourself!
| hestenet (he/him) | Tim from the DA kicking off our threads. |
| saschaeggi | Sascha from GitLab :wave: |
| quietone | Hi |
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.
2️⃣ As you saw in our last update, we made significant progress on the opt-in tools for migrating a specific project's issues from Drupal.org to GitLabA big part of that is also identifying all the other places issues referenced - and one notable area is Change Records.#3265112: Decouple change records from www.drupal.org issues
| hestenet (he/him) | You can see an in-progress work on handling issue references to GitLab in change records here: Approach:New link field was created and is multi-value. It requires absolute links.Old entity reference link has been hidden and will no longer be used.When combined with the work done on the gitlab migration issue, the links metadata is brought via JS.When viewing an issue linked to a change record, the change record is still visible as the view has been changed to try to match the any of the values of the new link field to the current issue being viewed.Change records can still be created from within a drupal issue and the issue will be prepopulated in the new format.A drush command was created to populate the new field with the values from the old (hidden) field, for all previous change records.Test:Change record listing: https://fjgarlin-drupal.dev.devdrupal.org/list-changes/config_notify/drafts (added field as POC, it can be removed if it’s not useful)Change record detail: https://fjgarlin-drupal.dev.devdrupal.org/node/3292914Issue mentioned in a change record: https://fjgarlin-drupal.dev.devdrupal.org/project/config_notify/issues/3... |
| fjgarlin | The parent issue contains a list of other affected areas within d.oThe approach taken in this issue will shape the others too so feedback is welcome |
| quietone | Looking good! I poked around at the links in the 'Test' section above and aside from the columns needing adjusting on the CR it does maintain the data and is usable. I do admit that I will miss the 'Review' button. |
3️⃣ There is work in progress on the GitLab side to add the per-project CI/CD quotas - which is our largest blocker outside of our control to mass roll-out for GitLabCI:https://gitlab.com/gitlab-org/gitlab/-/issues/351147Draft MR: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/91519The other major area is the transition strategy for DrupalCI->GitLabCI on a per-project basis (edited)
4️⃣ We are also refactoring the release creation process to use the GitLab API to grab the tags/branches: #3266212: Use GitLab API call to list tags/branches for creating releases
5️⃣ Account creation/login/access considerations:We are nearly sure we're going to be using GitLab's in-built ToS tool for the git terms of service, rather than a separate opt-in on D.O This needs to be coordinated with some other changes, and we need to do a bit of testing to validate how this affects user permissions. We also need to make some changes to put in place protections for certain types of accounts that are not allowed to commit code like 'shared accounts' and git_disabled accounts etc. - probably using an on_commit webhook
Participants:
hestenet, fjgarlin, quietone
Comments
Comment #4
hestenet