D.o. now hosts distributions. It should be possible to install a distribution on aegir just by providing a link to the raw build file.

Comments

anarcat’s picture

anarcat commented
Status: Active » Postponed (maintainer needs more info)

Actually, you can already do that by providing a link to the makefile, or did you mean the tarball?

lsolesen’s picture

lsolesen commented
Status: Postponed (maintainer needs more info) » Active

which make file from e.g. commerce kickstart should one link to

steven jones’s picture

steven jones commented
Category: feature » support
Status: Active » Fixed

To build the 7.x-1.x version you'll want to use this URL:

http://drupalcode.org/project/commerce_kickstart.git/blob/refs/heads/7.x...

omega8cc’s picture

omega8cc commented

No, you need to use raw URL (note the blob_plain): http://drupalcode.org/project/commerce_kickstart.git/blob_plain/refs/hea...

steven jones’s picture

steven jones commented

Doh, sorry, of course, thanks omega8cc.

lsolesen’s picture

lsolesen commented
Status: Fixed » Active

Sorry about the confusion, but I was talking about the 2.x-branch of kickstart: http://drupalcode.org/project/commerce_kickstart.git/tree/refs/heads/7.x...

steven jones’s picture

steven jones commented
Status: Active » Fixed

So in the 7.x-2.x branch you need to use the build-commerce-kickstart.make file:

http://drupalcode.org/project/commerce_kickstart.git/blob_plain/refs/hea...

lsolesen’s picture

lsolesen commented
Status: Fixed » Active

But that does not work, as the drupal-org-core.make file is included but Aegir did not clone the repository, so it cannot get it.

Include file missing: drupal-org-core.make
No core project specified.
Command dispatch complete
Peak memory usage was 6.42 MB
Could not download platform using drush make. No platform present

I just wanted to put the link to a build file into the aegir frontend and build the platform that way.

The Commerce Kickstart v2 project conforms to the newly introduced standards for building a project on D.O., but those build files cannot be used directly to build platforms on Aegir without having to clone the build files on the server directly (as far as I can tell anyways).

steven jones’s picture

steven jones commented

Sorry, do you have a link to these standards for building a Drupal.org distribution? seems like no-one else would be able to use the make file if they're all like this.

steven jones’s picture

steven jones commented
Status: Active » Postponed (maintainer needs more info)
iaminawe’s picture

iaminawe commented

I can confirm this problem with trying to install Commerce Kickstart 2 using Aegir - it seems the include chokes if the D.O make file is not not already there so remote install is not working.

lsolesen’s picture

lsolesen commented
Status: Postponed (maintainer needs more info) » Active

Here is the info about making a distribution, which can build on drupal.org

http://drupal.org/developing/distributions/drupalorg

omega8cc’s picture

omega8cc commented

@lsolesen Do you use Drush 5.x already?

omega8cc’s picture

omega8cc commented
Status: Active » Closed (works as designed)

Anyway, I believe that it is a bug to use local include in the stub makefile, as it makes it broken for anything other than local build on d.o

The correct stub makefile should use absolute URL to any included makefile, so there is nothing we can do about it on the Aegir end.

I would suggest to open a bug report against every distro following this "new standard".

lsolesen’s picture

lsolesen commented

@omega I am not using drush 5.x on my barracuda box.

mojzis’s picture

mojzis commented

@omega i have a feeling the local filename does have some sense - i.e. when building for tests form local repository ... wouldnt it make more sense to add an extra parameter to drush make, which would allow to specify the download location per run ? (something like if it aint available localy, get it on d.o. / elsewhere ?)

omega8cc’s picture

omega8cc commented

@mojzis No, it doesn't make any sense. Fix the problem, don't try to create workaround which could add even more complexity and compatibility issues (including backward compatibility). When you are using drush make with local stub makefile, you can edit it to reference local includes, if you wish, but when you are using remote stub makefile, you can't do anything. The stub makefile is useless if it depends on any local include, it is a failed logic, as it breaks the remote drush make completely. It is d.o who could automatically use the local include if it detects that the stub makefile references via absolute URL the file existing on d.o and shouldn't break things for the rest of the world.