Expose Git repositories containing only releases, to be used for deployment [#806484]

We discussed this quite a few times already, but I realize now we don't have an issue for it.

The idea here is to create, and automatically maintain, a "release" Git repository per project. This repository will have one commit per (published) release of a project, and will be used for deployment purposes.

It will allow anyone to build easily build a site-specific repository containing submodules pointing to those repositories. You could do that with the standard development repositories, but there are several advantages in having separate repositories:

The release repositories do not contain full history, and as a consequence are much smaller in size
The release repositories contain all the supplementary packaging information (think: you will not need a git_deploy module to make the update module work)

I have made a script to package those repositories, available my drupalorg-git repository. I launch it regularly on drupal.org, and the result is currently available as:

http://git.drupal.org/contributions-stable/*.git
git://git.drupal.org/contributions-stable/*.git

Comments

Comment #1

sdboyer CreditAttribution: sdboyer commented 29 May 2010 at 22:09

Issue tags:

+git phase 3

marking this phase 3 for now, though it could well be phase 2.

Comment #2

Josh The Geek CreditAttribution: Josh The Geek commented 2 April 2011 at 20:44

Note that these are no longer available
@Damien: In your code, line 20 has some missing quotes.

Comment #3

Damien Tournoud CreditAttribution: Damien Tournoud commented 6 April 2011 at 16:35

We put those offline not to make an already complex migration process even more complex, but those are still being generated (we have a Jenkins job for this).

A few things need to happen before we put those back up. From the top of my head:

(1) Proper review of the generation script, especially in regard to determine the "best available version" and the code that order versions
(2) Expose the repositories via the Git and HTTP protocols
(3) Document the repositories in both the Git instructions and the handbook

Comment #4

pwolanin CreditAttribution: pwolanin commented 6 April 2011 at 17:53

Are these taking in the content of the release tarball, or trying to take tags out of the main git repo?

Comment #5

donquixote CreditAttribution: donquixote commented 13 May 2011 at 00:07

My question would be, as in #4, does this repo match with the tarball? Esp., does it contain the LICENSE.txt, the additional lines added in *.info, and for older releases, the expanded $Id$ ?

My use case:
On an existing project, I want to use git to compare locally modified modules with the original version on drupal.org.
When I do this with the existing drupal.org git repositories, I get a lot of noise in changesets, caused by the lack of LICENSE.txt, and the $Id$ not being expanded.

So, there are two separate issues:
a) Is it ok if some site builders use module versions from git, that don't have a LICENSE.txt added? How serious is this, from a legal point of view? I don't have an opinion on this, but I imagine people will prefer the "safe route" if given a choice.
b) No matter if we or some site builder can live without the LICENSE.txt in future releases, I still consider it desirable to have the tarball contents from previous releases available via git, to compare and merge hacked versions of older releases.