#blocker

Automatically closed - issue fixed for 2 weeks with no activity.

Very close!

drpldrp → changed the visibility of the branch 2839195-10.3.x to hidden.

drpldrp → changed the visibility of the branch 2839195-10.3.x to active.

The only failing test is because of 📌 Cypress test publish-validation is flaky Active

I think that this removes blocker to further work on Migrate Plus Feeds module https://www.drupal.org/project/feeds_migrate →

Feedback appears to be addressed

Opened 📌 Research - If pluginbases from 2852463 can use mergeDeepArray Active for the follow up, please add more detail if you have time.

Hah, this conflicted with 📌 ComponentSource robustness: add `ComponentSourceTestBase::testSettings()` Active having introduced more test expectations, which this MR didn't yet add for the new test block + SDC.

Wim asked me to pick this up today. @isholgueras is offline in slack so hoping that's OK.. will push and unassign at the end of my day

What a fantastic start! 🤩👏

@f.mazeikis is on PTO.

> Update all of our API responses (both GET individual and GET list) to provide the entity operations' link relationship for those operations that are permitted

There's no individual GET for ApiContentControllers. I don't think this should be also on auto-saved data, so this should be good now?

📌 Manually test TUF-enabled Composer projects Active is where we’ve been getting some real-world testing

I think the memory usage looks a blocker: https://github.com/php-tuf/composer-integration/issues/127

Otherwise, we haven’t seen production issues in the last few weeks. When we do see them, they are hard to debug: https://github.com/php-tuf/composer-integration/issues/128

packages.drupal.org is TUF-enabled. For core, the drupal/* & php-tuf/* namespaces, there is packagist-signed.drupalcode.org to be added as another Composer repository. I’m guessing we might want a separate issue for adding the repository before packages.drupal.org

bbrala → closed merge request !11721