Skip to content
This repository has been archived by the owner on Aug 8, 2024. It is now read-only.

8.2.6 drops-8 scaffolding files #168

Closed
RainbowArray opened this issue Feb 5, 2017 · 6 comments
Closed

8.2.6 drops-8 scaffolding files #168

RainbowArray opened this issue Feb 5, 2017 · 6 comments

Comments

@RainbowArray
Copy link

I have Composer set up to get required scaffolding files from drops-8, like so, in the "extra" section of my composer.json:

"drupal-scaffold": {
  "source": "https://raw.githubusercontent.com/pantheon-systems/drops-8/{version}/{path}",
  "includes": [
    "sites/default/settings.pantheon.php"
  ]
}

In trying to do a composer update drupal/core for 8.2.6, I get the following error:

DrupalComposer\DrupalScaffold\Plugin::scaffold
Downloading: FailedScript DrupalComposer\DrupalScaffold\Plugin::scaffold handling the drupal-scaffold event terminated with an exception

[Composer\Downloader\TransportException]
The "https://raw.githubusercontent.com/pantheon-systems/drops-8/8.2.6/.csslin
trc" file could not be downloaded (HTTP/1.1 404 Not Found)

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.

@greg-1-anderson
Copy link
Member

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 repositories section. I'm leaning towards the later. Still a bit ambivalent, but it would solve a problem for folks who frequently rebuild their drops-8 Composer sites e.g. in CI.

@greg-1-anderson
Copy link
Member

@RainbowArray
Copy link
Author

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!

@markpdeeson
Copy link

+1 for something like this. The lack of 8.2.7 scaffold files held up our security releases for 24hrs

@greg-1-anderson
Copy link
Member

This would not make drops-8 releases come out faster; it would only prevent 404 errors during the time window between when a new tag was available on drupal.org, and when the same tag became available on drops-8.

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.

@markpdeeson
Copy link

it would only prevent 404 errors during the time window between when a new tag was available on drupal.org, and when the same tag became available on drops-8.

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants