Project:Drupal.org drush
Component:Code
Category:bug report
Priority:normal
Assigned:Unassigned
Status:active

Issue Summary

We have a drupal distribution http://drupal.org/node/1890706 that does not show the 'In this package' details. This doesn't appear in commerce_kickstart either
http://drupal.org/node/1899400 but does appear on the spark releases http://drupal.org/node/1901600

Comments

#1

I inspected the project_package_local_release_item table in the DB, and it looks like this is a problem with the table being populated.

Query on a Spark release node:

SELECT * FROM project_package_local_release_item WHERE package_nid = 1901600;

package_nid item_nid
1901600 0
1901600 405854
1901600 999344
1901600 1044008
1901600 1460550
1901600 1650068
1901600 1662780
1901600 1672954
1901600 1722476
1901600 1733788
1901600 1736460
1901600 1738460
1901600 1738468
1901600 1751522
1901600 1799508
1901600 1802928
1901600 1860642
1901600 1873988
1901600 1898494
1901600 1901356

Query on agov:

SELECT * FROM project_package_local_release_item WHERE package_nid = 1890706;

package_nid item_nid
1890706 0

Thanks to the sleuthing of Dave Reid: http://drupalcode.org/project/drupalorg.git?a=search&h=refs%2Fheads%2F6....

We know that this is probably a bug in http://drupalcode.org/project/drupalorg.git/blob?f=drupalorg_project/plu.... It's doing some kinda funky thing with Drush and saving package info to a temp dir or... I dunno.

Halp! :)

#2

I just pushed a new release of aGov, and still don't have the package contents info.

It must be some quirk of the make files?

Kim

#3

Project:Drupal.org infrastructure» Drupal.org drush
Component:Packaging» Code

I looked into this. The problem that we have is that the generated metadata-contrib.json file contains multiple JSON objects smushed together. For example, a test run on Commerce Kickstart gives us:

https://gist.github.com/damz/cc1b78fc7e9f9f66465d

I assume that this is because of recursive runs of Drush Make (ie. the chosen module is checked out, and it contains itself a make file that gets processed separately). I assume this is a Drupal.org drush bug / limitation. Reassigning there.

#4

We cannot prevent Drush from spawning a new process for recursive processing, so I see two options:

  • We pass a directory instead of a file to --drupal-org-log-package-metadata. In DrupalorgProjectPackageReleaseDistro, we load all the *.json files in this directory and recursively merge them.
  • We make sure to frame our JSON exports (for example by a \n character, which is a common framing boundary for multiple JSON data in a stream). In this case, we probably also want to lock the file (with flock) during the write operation, as writes are only guaranteed to be atomic up to PIPE_BUF characters. In In DrupalorgProjectPackageReleaseDistro, we decode each JSON object from the stream and recursively merge them.