Local stub makefiles
These stub makefiles contain relative links to the various includes. This means that you need to have a local kPlatforms directory, so that the included makefiles will be in the correct places.
- Use-case for local stub makefiles
- The use-case for local stub makefiles is in building platforms where you record version tags via platform naming conventions (or comparable methods), and want to maintain a local kPlatforms repo. Also, to rebuild a platform that used a remote stub, you'll need to use the local stubs to ensure the resulting platform is identical.
Remote stub makefiles:
These stub makefiles contain remote links to the raw Git output of the latest versions (on the same branch) of the included makefiles. This mean that you don't have to have a local kPlatforms directory, and can build platforms by just using the raw Git output of the stub makefiles.
However, the included makefiles point to the latest head in the same branch. As a result they are dynamic. A platform built from the same (git commit of a) stub may end up different, if changes have been made to any of the included makefiles.
- Use-case for remote stub makefiles
- The use-case for remote stub makefiles is to be able to keep a record of the exact makefile used in creating an Aegir platform, while avoiding having to maintain a local kPlatforms repo.
Discussion
Think of it as the Aegir equivalent of the Heisenberg Uncertainty Principle. With local stub makefiles you can re-build an exact duplicate of a platform, but you won't necessarily have a record of the exact tag/commit associated with the platform in Aegir. With remote stub makefiles, you'll have a record of the exact tag/commit associated with the platform in Aegir, assuming you passed in the raw view of a git tag or commit when building the platform, but you won't be certain that a new platform built using the same url will result in an identical platform.
Examples
A few weeks ago, you built a platform in Aegir using a remote stub makefile. The current tag at the time was 7.x-6.4, so you used the following url in the 'makefile' field when building your platform:
http://drupalcode.org/project/kplatforms.git/blob_plain/3e04b52cc09538f4cfe900b2fb0787cf62326e0f:/stubs/Drupal7.make
Now, you receive a request from a developer to create a local version of a site hosted on this platform. By providing her with a recent backup of the site, she'll have any site-specific themes, modules, &c., along with a copy of the database, with credentials encoded in settings.php. However, to build an equivalent platform, she'll need to do the following:
git clone http://git.drupal.org/project/kplatforms.git
cd kplatforms
git checkout 3e04b52cc09538
drush make stubs/Drupal7_local.make <path_to_desired_platform_root>If, instead of using the url to the makefile, as described above, you had built the platform from a local stub makefile, hopefully you will have named the platform with the git tag, or provided some other documentation to identify the exact version of the makefile used. In such a case, instead of checking out the commit, you could checkout the tag (in this case, 7.x-6.4) which should be equivalent.
Of course, it's possible, if tricky, to figure out the exact commit from the date and time the platform was created as well. But, this assumes you were using the latest head at the time, and so isn't as reliable as the other techniques described above.