8.8.0 tarball => 8.8.1 fails update

This is very likely an d.o infrastructure issue that surfaces w/ 8.8.

We get things like vendor/doctrine/inflector/.gitignore not existing when rolling back an update from 8.8.0 => 8.7.0.
But this is a failing test.

Fix phpcs

Fix up a few more failing tests since we use a new method to get an actual tarball instead of a git clone.

What exactly is the potential infrastructure issue? I verified that the shasum of composer.lock looks consistent everywhere for the fresh downloads of the 8.8.0 release:

➜  ~/Downloads/tmp curl --silent http://updates.drupal.org/release-hashes/drupal/8.8.0/contents-sha256sums-packaged.csig | grep '(composer\.lock)'
SHA256 (composer.lock) = aab6c4763bb0553026bbd38b82e74f391c791569533361183d9060dd08c889b5
➜  ~/Downloads/tmp shasum -a256 tgz/drupal-8.8.0/composer.lock
aab6c4763bb0553026bbd38b82e74f391c791569533361183d9060dd08c889b5  tgz/drupal-8.8.0/composer.lock
➜  ~/Downloads/tmp shasum -a256 zip/drupal-8.8.0/composer.lock
aab6c4763bb0553026bbd38b82e74f391c791569533361183d9060dd08c889b5  zip/drupal-8.8.0/composer.lock

Since 8.8.0, the packaged downloads of tarballs/zip files for the releases are now built using Composer as part of the packaging process. I think this may mean that the not-compatible-with-composer restriction kicks in for Drupal 8.8.0+, regardless of installation method.

Since 8.8.0, the packaged downloads of tarballs/zip files for the releases are now built using Composer as part of the packaging process. I think this may mean that the not-compatible-with-composer restriction kicks in for Drupal 8.8.0+, regardless of installation method.

Oh hell, this is probably the reason. Even tarball installed sites will appear to be 'sites using composer' after the composer initiative, so when we decided to just roll-back as un-updateable sites built with Composer.... we kind of chased our own tail there.

I wonder if we can detect 'built with the default composer but not changed yet'... oi...

No, the issue seems not to be d.o infrastructure related per se, but the logic we are using to decide if something is packaged or not is/was triggering off if datestamp was set in info.yml. This does not seem to be the case for 8.8.0. We'll need to figure out another way to determine if the site is installed using packaged vs non-packaged source.

This will hopefully fix the issue.

This should handle things like drupal 9 and 10 version a lot more cleanly. And it means we do not need one-off logic for 8.8.0-alpha1, 8.8.0-beta1 that used the old packaging method.

Oops. Patch attached.

Thanks for reporting the error @herrzhull, and to @heddn for fixing it.

I can confirm that the reported error happens if you try to update Drupal 8.8.0 tarball with the latest stable release of Automatic Updates. I have repeated the process with the patch against latest dev-release of Automatic Updates and the Readiness checks as well as update goes through smoothly.

When will be the patch usable? I just applied the current 8.x-1.1 publicly available on a clean 8.8.0 but keep getting:

Your site does not pass some readiness checks for automatic updates. Depending on the nature of the failures, it might effect the eligibility for automatic updates.
The hash for .ht.router.php does not match its original. Updates that include that file will fail and require manual intervention.

and so on. Am I doing something wrong?

@miguelsanmiguel it should be resolved right now.

FWIW, I installed Drupal 8.8.2 via composer, then installed the automatic updates module via composer. I am still getting the following:

Your site does not pass some readiness checks for automatic updates. Depending on the nature of the failures, it might effect the eligibility for automatic updates.
The hash for composer.json does not match its original. Updates that include that file will fail and require manual intervention.
The hash for composer.lock does not match its original. Updates that include that file will fail and require manual intervention.
The hash for vendor/composer/installed.json does not match its original. Updates that include that file will fail and require manual intervention.
The hash for vendor/composer/autoload_psr4.php does not match its original. Updates that include that file will fail and require manual intervention.
The hash for vendor/composer/include_paths.php does not match its original. Updates that include that file will fail and require manual intervention.
The hash for vendor/composer/autoload_files.php does not match its original. Updates that include that file will fail and require manual intervention.
The hash for vendor/composer/autoload_static.php does not match its original. Updates that include that file will fail and require manual intervention.
The hash for vendor/composer/autoload_real.php does not match its original. Updates that include that file will fail and require manual intervention.

I'm uncertain how to best proceed. I did a Google search on the message, and was brought to this thread.

Current limitation is we don't support composer based installs: https://git.drupalcode.org/project/automatic_updates#installing-the-auto...

We're working on a solution for that in #3104116: Supporting composer-based site installs, but until then you won't be able to use this module in the way you wanted to.

So if I'm understanding you correctly, the basic answer is, "Wait it out."?

For your use case of composer, yes. Or use it on sites that don't use composer.

FWIW - we've put out a call for further sponsors to help us complete the composer support and other outstanding features that we'd like to include in this system: https://www.drupal.org/drupalorg/blog/request-for-sponsors-automatic-upd...

Thanks @hestenet, I hope some organizations decide to sponsor further development. And thanks @heddn for all the great work you have already done.

@BEGRAFX: Drush 8, with classics like drush dl and drush up (update core or module code -> run drush updb) still works with Drupal 8. So as long as you don't use modules which require Composer, it's technically possible to maintain Drupal 8 without Composer.

It would be so awesome to get the drush dl and drush up commands included in Drush 10, so that Drupal users are not forced to use Composer. This way it would be possible to build and update a Drupal 8 web site the good old way, with drush dl and drush up, while having the freedom to use the Automatic Updates module to keep the web site updated and secure.