Create a service to composer install via package_manager from Automatic Updates

I’ll give this feature implementation a try. Will update on my progress accordingly.

I have added an MR (Not sure when we create MR in this new workflow, more of a patch person) with a very basic implementation of connection with the Package Manager and also included work/suggestions by @grasmash. It will still require considerable work to take this to the finish line. Looking for suggestions/feedback regarding a few items:

1. I have added this change in the .info.yml file as that's how the Automatic Update module was indicating dependency on Package Manager. But as of now, the Package manager is still isn't part of the core and the user will have to clone 8.x-2.x in local to test the working of this MR.

dependencies:
  - drupal:package_manager

2. When hitting the download button in the Svelte app, the following issues still have to be addressed:

• The Drupal controller doesn't receive value for the project machine name in the request. Some debugging is required in the Svelte code for this.
• If the download fails for any reason, the very next time user hits the download button, the system gives the following error 'The staging directory already exists at "/tmp/.package_manager..........'. Will have to check with the Automatic Updates team regarding this.
• Package manager is throwing a 504 error whenever an installation is requested. This can happen for any system. Not sure what's the plan in that case.
• Svelte app isn't showing any loading throbbed after hitting the download button and would also require CSS changes once we have finalized where the download button would be.

Per discussion in Slack I reverted this commit

I think we should change this issue to just implementing an API callback that Javascript will use in follow-up to install the module. If we also provide a Functional test to assert the correct response and assert that module was actually enable it should be enough to prove it works. We would need those test anyways.

Some suggestions for creating a test:

1. Making the no errors should be easier be so do that first
2. You can use the httpclient see core/modules/editor/tests/src/Functional/EditorSecurityTest.php
   

   $response = $client->post($this->buildUrl('/editor/filter_xss/' . $format), [
             'body' => http_build_query($post),
             'cookies' => $cookies,
             'headers' => [
               'Accept' => 'application/json',
               'Content-Type' => 'application/x-www-form-urlencoded',
             ],
             'http_errors' => FALSE,
           ]);
   
           $this->assertEquals(200, $response->getStatusCode());
   

3. for setting a package_manager error see \Drupal\Tests\automatic_updates\Functional\UpdaterFormTest
   We just create a new module package_manager_test_validation in #3249983: Create a test module in Package Manager for testing stage validation that you can use(have to pull changes)

   probably use it something like this
   <?
   $error = ValidationResult::createError([$message]);
   TestSubscriber::setTestResult([$error], PreRequireEvent::class);

4. You will have to make project_browser dependent on package_manager, we can this optional later
5. to get drupalCi to work I think you need update the compser.json to require-dev drupal/automatic_updates:2.x-dev
6. We will need at least 3 test methods,
   a. no errors installs module
   b. errors, make sure they come back in json response
   c. access error, a user without access should get 403
7. for now just use real module on drupal.org to install. we will have fake this later. might need to convert to build test like \Drupal\Tests\automatic_updates\Build\CoreUpdateTest but can do that later

@tedbow, thanks for the overview.

I believe this might be a duplicate of https://www.drupal.org/project/project_browser/issues/3284945

I chatted with @bnjmnn about re-opening this issue.

The way #3284945: Install endpoints that leverage Package Manager + core APIs is currently scoped it will need to create the UI changes needed for actual installs and create the integration with package_manager. To do this correctly it will also need to create the test coverage for both parts and make sure it is secure. That is a lot for 1 issue.

@bnjmnn agreed with me that we should re-open this issue to make the scope of #3284945: Install endpoints that leverage Package Manager + core APIs much smaller.

Also tackling the only the API integration with package_manager its own issue will keep this issue much smaller in scope and make it much easier to review by myself and/or the other developers that have been working on the Automatic Updates module

We have multiple merge requests so I am trying to consolidate the work into 1 branch.

I chose merge request 12 mostly because merge request 62 uses the branch name 1.0.x that doesn't work well with the "Show commands" boxes at the top of the issue provided by drupal.org.

I did cherry-pick all the commits though the commits that @bakulahluwalia made though and brought them over to the MR 12. I also clean up most of 62 to be inline with the testing from 12. The module won't need a controller to test the service as this will be provided by the test module project_browser_test_api. this will allow this merge request to be much smaller by only providing the new service and the testing for it.

A lot of stuff has changed in package_manager since these merge requests were last worked so I will leave notes on the MR

Created #3299285: Change automated tests to use 7.4 and maybe add PHP requirement to 7.4

For now to get the MR to pass test you have to add a PHP 7.4 to this issue instead of 7.3.

The tests are passing now

Setting to Needs Review as tests are passing using PHP 7.4 which Automatic Updates requires

I made a couple of questions in the MR and also highlighted the fact that projects might not come from the `drupal/project_name` namespace for composer.

@fjgarlin thanks for the review. I commented/updated on all your points. Setting back to needs review

We have tests now so removing tag

Updating IS because the testing workaround is no longer needed.

MR 12 had a very difficult commit history to rebase, so I've moved the current changes to a new MR: 227. The two active threads on MR 12 were moved over as well, in the form of me quoting the originals.

Alright! MR 227 is the one to review

This is looking great! A couple points of feedback (which are already being discussed), so I'm changing the status for now.

Addressed all MR comments

Great, thanks @kunal.sachdev and @tedbow! That resolved all my feedback. Leaving at RTBC for a bit just in case someone else chimes in first, but will commit soon.

Adding phenaproxima who commented on the MR in gitlab.

9 months after reverting the original MR, we're back with a real API! Thanks everyone!