Does https://www.drupal.org/drupal-wiki → have a “⭐️ Following” widget that you can click to unfollow?
I believe that is where the link should be, but the top-level documentation pages have some uniqueness in how they are set up.
We don’t have the GitLab superuser with ID 1 mapped to a Drupal.org account. So DrupalOrgIssueForksQueueWorker::getAccessLevel() will always return 30. We could make that a class constant.
We’re up to 20 max attempts configured in D7, and that’s with the increasing delay between each attempt. A recent nearly-worst-case example is a fork that took 5 minutes to be available in GitLab. As discussed in Slack, there isn’t good queue delay support:
- The queue we use has a trick with a second queue: https://builder.aws.com/content/2zD6mhH6z6FVSNwjyrtX2DlEtmx/using-ttl-to...
- The core database queue looks like the only Drupal implementation with a delay. The same
drush queue:runcommand we use to watch RabbitMQ looks like it could do a polling loop for the DB queue, constantly querying to see if an item is ready. It could work but doesn’t feel great - We could have 2+ RabbitMQ queue runners and
sleep() - We could set up some other contraption
Before we get into any of that, maybe we can avoid post-fork actions. There has been some progress on https://gitlab.com/groups/gitlab-org/-/epics/607 that looks promising, but testing on GitLab.com does show there is definitely still an import delay until the repository is available. I was able to update the fork project’s description before import finished, so I’m optimistic we can do more upfront.
The initial forking in IssueForksController::issueForkCreateFork() should go ahead and immediately:
- Add the user as a member, this is what we do in D7, so we know it works and doesn’t take long
- Add the issue note, it’s not dependent on the fork being complete (this would be fine to defer to a queue if it does cause significant delay, and does not need retries in the same way)
- We should try
$client->projects()->update($fork['id'], $options);and see if GitLab now supports project updates before import finishes
If that works, that only leaves branch creation - let’s leverage the frontend, JS has setTimeout() & setInterval() so it can check GitLab’s API for the project‘s import status every ½ second. Once imported, it will have to send the branching request via Drupal, to use our bot user’s access.
Since no code was pushed to git.drupalcode.org for these projects, I was able to delete them.
If I enter </code>avpaderno_<code>avpaderno_</code> with the current code, which calls l(), I get the following.
That is not what the code actually did. $item['#markup'] is already escaped by the point this code gets it, so the change you requested ends up double-escaping. Escaping usually needs testing on a dev site.
We can keep URLs constructed like l(t('Link label'), 'user/959536/contribution-records') and the CDN will redirect (node|user)/[0-9]+/contribution-records to new.drupal.org.
Changing some language to fix URL auto-linking, and make it explicit that “GitLab” means git.drupalcode.org.
This is all done, along with some additional case-study-related improvements.
This UI would end up being pretty tricky to build, depending on how you define “certain issue types.” I could imagine wanting to match GitLab labels or pattern matching the issue title. (We are not doing extra integration with www.drupal.org issues as those are being replaced with GitLab issues.) So we‘d have to figure out what exactly goes in the UI, who updates it, where it lives, etc.
While we do want managing issue credit to be straightforward and consume as little time as possible, I also wouldn’t want to see crediting decisions put on autopilot. On the form but not credited would be a good idea. While there are meetings with regular attendees, the vast majority of issues are not meetings.
Community events ( https://www.drupal.org/community/events → ) do show on user profiles, and sponsors show on organization pages, so those are good for crediting events.
The release which showed this problem has been reprocessed and is fixed, https://www.drupal.org/project/ui_icons/releases/1.1.0-beta5 →
Steps to reproduce from Slack were:
cd $(mktemp -d)
composer create-project drupal/recommended-project:10.5.3 .
composer config minimum-stability beta
composer require drupal/ui_icons
cat web/modules/contrib/ui_icons/ui_icons.info.ymlFailed to create wiki has not happened in the last 6 months, and I have some memory that issue might have been resolved, so that exception handling can be removed too.
Just to confirm, the unpublished https://www.drupal.org/node/3499495 → & https://www.drupal.org/node/3499788 → will be deleted before the redirect is added. Is the deletion okay?
Updating instructions since there is no longer a self-serve option for updating releases.
Done, and I’ll update the documentation. Since many projects moved away from their master branches already, we simplified our codebase to remove the self-service option at some point.
Adding a little bit of history on why merge trains are enabled by default.
Please go ahead and make an initial commit of the module code. We normally do not do project type changes preemptively.
There was a request for updated data in Slack, it is attached.
More notes for myself for next time:
Get the current core components:
SET group_concat_max_len = 10000000000; SELECT group_concat(DISTINCT pcc.name SEPARATOR '\\|') FROM project_composer_component pcc INNER JOIN field_data_field_release_project fdf_rp ON fdf_rp.entity_id = pcc.release_nid AND fdf_rp.field_release_project_target_id = 3060\G
Filter the usage data:
grep '\sdrupal|.*\([the core components]\)$' < /var/log/updatestats/counts/[most recent].submodule_release_counts > drupal-component-usage-by-release-[today].txt
I guess tackling this challenge will also be relevant, even after moving issues to GitLab?
Yes, this will still be relevant, regardless of where issues are.
The best place I can think of putting this is maybe the “Administer releases” page, and/or something on each release page. Drupal.org’s DB does not have the default branch, so any specific messaging would need a front-end JS request to gather data, or have the very generic “Remember to match the default GitLab branch with the latest [or active?] dev release.”
As we migrate issues to GitLab, there will no longer be the opportunity to add button styling, or add arbitrary text to the issue UI. So we somewhat do want to make sure people are looking for the link without making everything bigger.
We will be able to post automated comments, like the “Now that this issue is closed…” comment you see on this issue, and we’ll also post an introductory comment. That will be styled like any other comment in GitLab, so we can start thinking about copyediting improvements that could help. Updating the automated comment as credit is updated would be a stretch goal.
🌱 [PP-1] Create components for a default design system Postponed is one more test update, including the version field update.
I’ll assume the copyediting has been reviewed enough and move forward with updating the 539 issues.
I’ve removed the block from node/*/edit pages with block visibility settings.
I finally decided on a wording and this is deployed. With 📌 Move issue credit listings to new.drupal.org Active split off into a separate issue, I think this is now fixed. Please reopen if I missed anything.
I opened 📌 Improve logging in locale_translation_download_source() Active to get more detail in the “Unable to download translation file…” log message
I opened
📌
Improve logging in locale_translation_download_source()
Active
to get more detail in the “Unable to download translation file…” log message. This issue looks like it is focusing on better handling than TypeError: fgets(). I think it makes sense to tackle both issues separately, to keep each issue more straightforward.
Unable to download translation file https://ftp.drupal.org/files/translations/all/restui/restui-8.x-1.22.fr.po
This error comes from locale_translation_download_source() and might be HTTP connectivity or issues with saving the file locally. Unfortunately, there is not enough detail in this log to know which issue it is. And if it is indeed an HTTP issue, it doesn’t have enough detail to start tracking it down.
I’d like to see the specific exception type, message, and HTTP status code & response if it is an HTTP error.
TypeError: fgets(): Argument #1 ($stream) must be of type resource, bool given in fgets()
is a side-effect of of the first error. 🐛 PoStreamReader::readLine() throws an error on module install Needs work has some work toward improving this error handling.
I haven’t been able to find any potential issues with serving these files for Drupal or Drush. Since the error may be with saving the file to the downloaded translations, I’d start with finding where it is writing and triple checking the permissions, making sure the user account running drush write access.
Something caused the migrated project maintainership data to be cleared. I’ve re-migrated the data, and the integrity checks look clean enough. So this is resolved, for now.
Leaving open since we need to do more log analysis & checking over things to figure out the root cause, make any necessary improvements, and get the integrity checking automated so we have good alerting for any future inconsistencies.
Thanks for the good bug report! This was also reported at 🐛 Issue credit controls doesn't follow permissions Active
We had another report of this that included a URL, so it was easy to track down. We do currently have a bad migration of project maintainers.
Are you logged into new.drupal.org? Its impossible to tell with the cropped image and no URL provided.
As part of simplifying Drupal.org and letting GitLab handle things it is good at, we no longer have commit listings on Drupal.org.
We removed our merging UI with ✨ New contribution records system Active
We removed our merging UI with ✨ New contribution records system Active
With ✨ New contribution records system Active , we no longer have per-comment attributions.
With ✨ New contribution records system Active , this no longer happens. There will just be the one-time notification.
Drupal.org no longer keeps commit-related information in its local DB, so this is not practical to implement. GitLab provides APIs on git.drupalcode.org. https://docs.gitlab.com/api/
This UI has moved with ✨ New contribution records system Active , and does explicitly mention that it is for copy/paste.
Hopefully this is no longer happening, especially with the new credit system. Of course, reopen with details if it does.
With ✨ New contribution records system Active , we no longer record attribution for each comment.
With #3039289: Make issue credit assignment comments visible → , crediting is no longer deeply integrated with updating issues.
This no longer happens, as part of wider changes to not suggest credit.
This part of the UI is now removed, we no longer track attribution per-comment after ✨ New contribution records system Active
The post-migration cleanups in D7 are now in place, removing access to credit-related fields. So the outdated data is no longer accessible, this is the only API. I think we can say this is fixed as there is documentation in place.
We’re no longer automatically suggesting credit, and this UI has moved with ✨ New contribution records system Active . Marking this fixed since I believe I did put a fix in place at the time.
With ✨ New contribution records system Active , we are no longer recording attribution per-comment, so this UI has been removed.
This has been deployed for awhile and the immediate followups & cleanups have been triaged & fixed. 🎉
Any future followups should be their own issues.
https://www.drupal.org/node/2373279/issue-credits → is paged, showing the first 50 issues, with 21 more pages. So everything is consistent as far as I can tell. This is all counting just the last 12 months, which is what currently matters for rankings and program eligibility.
Is there something I might be missing or an approximate number you expect to see?
Re 500 errors - right now the issue credit listings are especially fragile, since the D7 site makes HTTP requests to the new site as part of its own page rendering. We have lowered the timeout when making the Guzzle requests in D7, so that should limit the 500 errors, but if we missed something, or we’re making 4 requests that use most of their allowed 10s, that will 500. The setup is indeed fragile. Rather than sinking time into making this work better, we should get the Views moved: 📌 Move issue credit listings to new.drupal.org Active
In the cleanup at https://git.drupalcode.org/project/drupalorg/-/commit/54fdf4bd59067dbf47..., I brought back creating the hidden comments which should allow the names to transfer over. There’s one more followup at https://git.drupalcode.org/project/drupalorg/-/commit/ab02815e40efd30a56..., field_issue_credit should no longer be used anywhere.
This will get the names transferred over. Manually checking the boxes on the contribution record to actually grant the credit will be a necessary step. Leaving at needs review to double check this with the next advisory being published, and we might do a followup to automatically credit everyone for advisories.
This is actually the first time we’ll be sending email from new.drupal.org, and this has reminded us that we hadn’t set up outgoing email yet. That infrastructure setup is in progress.
I’m seeing 2 remaining edge cases:
- The “current” bit is sometimes mismatched between sites.
- I didn’t get job title in the diff, and I believe we will have issues there.
The short name for https://www.drupal.org/sandbox/eyalshalev/2767919 → has been reset, and you should be unblocked.
But how is possible for sandbox project to take a short name? For years I was convinced that only permanent/full projects are owning a a short name.
This should be true, but the enforcement is via a couple essentially multi-step forms implemented in D7 and earlier, so bugs have happened.
I like the more-lightweight format in #5. The spacing between lines could be reduced.
https://www.conventionalcommits.org/en/v1.0.0/ only specifies feat/fix or the ! appended. It looks like the list is up to each project to decide what makes sense for them. Is this set what makes sense for Drupal? How do we decide that? How do we decide when someone asks for another option.
I’ve packaged up the integrity checking as a shell script. Spot checking makes it look like a decent first pass.
The list of uids with a diff is:
sed -ne 's/^[+-][^\t]*\t\([0-9]*\)\t.*/\1/p' < user-organizations.diff | uniq
If that’s accurate, this currently affects 3,604 people.
And the initial version for the new site
SELECT ufd.name, ufd.uid, p_fon.field_organization_name_value AS organization_name, p_for.field_organization_reference_target_id AS organization_nid, p_fc.field_current_value AS current FROM users_field_data ufd LEFT JOIN user__field_user_organizations u_fuo ON u_fuo.entity_id = ufd.uid LEFT JOIN paragraph__field_organization_name p_fon ON p_fon.entity_id = u_fuo.field_user_organizations_target_id LEFT JOIN paragraph__field_organization_reference p_for ON p_for.entity_id = u_fuo.field_user_organizations_target_id LEFT JOIN paragraph__field_current p_fc ON p_fc.entity_id = u_fuo.field_user_organizations_target_id ORDER BY ufd.uid, organization_name;
For integrity checking, this is an initial query for a users at organizations manifest in D7. I has all users, so we get a username integrity check too. If we want to narrow the scope, some LEFT JOINs can be INNER
SELECT u.name, u.uid, fdf_on.field_organization_name_value AS organization_name, fdf_or.field_organization_reference_target_id AS organization_nid, fdf_c.field_current_value AS current FROM users u LEFT JOIN field_data_field_organizations fdf_o ON fdf_o.entity_id = u.uid LEFT JOIN field_data_field_organization_reference fdf_or ON fdf_or.entity_id = fdf_o.field_organizations_value LEFT JOIN field_data_field_current fdf_c ON fdf_c.entity_id = fdf_o.field_organizations_value LEFT JOIN field_data_field_organization_name fdf_on ON fdf_on.entity_id = fdf_o.field_organizations_value ORDER BY u.uid, organization_name;
This is now published. Likely there was some race condition which two versions of the node were saved at the same time.
I moved this to a fresh block implementation so we’re not relying on the old block being placed. This is deploying soon.
I recommend creating the 0.x-dev release for canvas before bulk updating issues. This will allow issues with the 0.x version to have that option available once moved.
https://www.drupal.org/project/canvas/issues/3439664 🌱 [later phase] Research Issue For Workspaces Extra Postponed is the test issue for final review before I start the bulk update. Note the version field would need to be updated on the next issue update. Assuming the version was 0.x-dev, adding the release will fix that.
Do we want to move closed issues too, or just open issues?
https://gitlab.com/gitlab-org/gitlab/-/issues/566636 did get at least one bugfix backport moving in GitLab. They did spot a typo in our configuration which was very likely to be the cause. I’ve corrected the typo and reconfigured, so I expect this to be resolved. Please reopen with details if this does happen again.
We’ve had some other reports that have potential to be the same issue. We need the line with the correlation_id from GIT_CURL_VERBOSE=1 git push to confirm it is the same issue, or track down something else. For example:
17:22:43.565250 http.c:662 <= Recv header: X-Gitlab-Meta: {"correlation_id":"01K3V6S15E9B305CFY6QCCRABF","version":"1"}
drumm → created an issue. See original summary → .