-
Notifications
You must be signed in to change notification settings - Fork 117
8.2.6 drops-8 scaffolding files #168
Comments
Sorry about this. I rewrote my update script for 8.2.6, and forgot to push the tag at the end. The tag is in the repository now, so your builds should work again. Note that there still will be a time period where you will experience problems such as the above when new versions of Drupal are released. Drupal-scaffold decides what version to use for the scaffold files based on what version Composer picks for drupal/core. A new version of drupal/core will be available as soon as it is released on drupal.org, but drops-8 will not contain the new tag until the release is tested and released for Pantheon. During this time, you will continue to experience symptoms as shown above. I have considered making an exact clone of drupal/core at pantheon-systems/drupal-core (on github) that varies only insofar as the release tags are not made until drops-8 is released. I'm not sure if I should rename the project (more complicated to implement, discouraged by Packagist), or just have users add a new entry to their |
Thanks for the update. Got everything working on my site now. I think I'd probably lean toward a new entry in the repositories section too. That would help make it much easier to keep everything in sync. Waiting a couple days isn't the end of the world unless it's an urgent security update, but I suspect you'd be on top of getting those out pretty quick. Thanks so much for all you do! |
+1 for something like this. The lack of 8.2.7 scaffold files held up our security releases for 24hrs |
This would not make drops-8 releases come out faster; it would only prevent An alternate strategy might be to install the scaffold files directly from drupal.org, and apply the Pantheon files from a separate project, perhaps via cweagons-patches. This would get you your security updates immediately upon release from drupal.org. That certainly sounds like a good thing, but the downside is that all of the composer users would then be able to upgrade their own sites before Pantheon had a chance to test the release on the platform. Our current policy is to not release until after internal testing has been done. Generally, testing does not uncover any problems, but I'm unsure about taking the step to eliminate it entirely. |
This is exactly the issue we have. Our CI system can't build a release because it depends on a handful of scaffold files which are 404'ing. Many of these are core Drupal files, but also settings.pantheon.php and so on. We may well not push it out live before Pantheon's internal team has approved the release, but until we can build the project we can't run our internal QA and our clients can't run their user testing either. Thanks for the composer-patches suggestion, I'll certainly take a look at that approach. |
I have Composer set up to get required scaffolding files from drops-8, like so, in the "extra" section of my composer.json:
In trying to do a composer update drupal/core for 8.2.6, I get the following error:
Since 8.2.6 was only released a couple days ago, does it take a couple days for the scaffolding files to be available at the raw.githubusercontent path? Is that something that needs to be manually generated? It would be good if that was available as soon as possible after a release. Particularly if there's a security release, being able to run this update as soon as possible would be important. Since I deploy to Pantheon with Circle CI, this error breaks my build.
The text was updated successfully, but these errors were encountered: