14

We have multiple git repositories for different projects. There is also a git repository for infrastructure purpose. We have custom gradle plugins written in this infrastructure repository which we use in other repositories

Example:

buildscript {
    apply from: 'foo/bar/devinfra-buildscript.gradle', to: buildscript
}
apply plugin: 'devinfra'

Here we are having the buildscript{} file, foo/bar/buildscript.gradle in every Git repository. I want to know if there is a way where we can apply the file directly from a infrastructure repository. So that any change is visible across other repositories directly.

Sundeep Gupta
  • 1,887
  • 3
  • 24
  • 35

3 Answers3

18

In that case, you could add a git subtree Merging (different to git subtree) to each of your repo, referring to the infra repo.

git read-tree --prefix=<subdirectory_name>/ –u <shared_library_branch>

You can see a study doing that in "Managing Nested Libraries Using the GIT Subtree Merge Workflow".

http://www.typecastexception.com/image.axd?picture=Subtree%20Illustration_thumb_1.png

In your case:

cd /path/to/project
git remote add infrarepo /url/to/infra/repo
git fetch infrarepo
git checkout -b infra infrarepo/master

git checkout master
git read-tree --prefix=infra/ –u infra
git commit -m "Add Infra subtree"

To update the project repo with subtree changes:

git checkout infra
git pull
git checkout master
git merge --squash –s subtree –-no-commit infra
git commit -m "update infra"

To update the subtree repo with change from the subtree folder of the project repo:

git checkout infra
git merge --squash –s subtree --no-commit master
git commit -m "(infra subtree) nature of changes"

git push infrarepo infra
Michael Freidgeim
  • 26,542
  • 16
  • 152
  • 170
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
6

The answer depends on what exactly you're going to achieve.

  1. If you simply want to update your build file in one place and "automagically" receive the changes in all project repos, then you probably should take the file out of GIT control and, for example, simply use a link or something like that to an outer location.
  2. The second option is to move all the build stuff into a common directory, make that directory a separated shareable GIT repository and then plug-in that repository in all your projects repos, e.g. as a submodule But in this case you won't receive "automagical" updates because git strictly binds submodule content to a particular commit in the submodule and une need to run git submodule update and subsequent git commit to receive updated contents in your project repos. The variant of this method is git subtree merge proposed by @VonC
  3. If your build machinery is complex enough you may want to consider creating a "gradle artifact" and hide the complexity there. Then you may plug in that artifact to your projects and rely not on a particular version of the artifact but rather on a range of versions
user3159253
  • 16,836
  • 3
  • 30
  • 56
  • the plugins are in artifactory (gradle artifact). But to pull those artifact each consumer build.gradle (in other git repos) will have to add buildscript{} block, to specify the repository + dependency config. I was trying to find a solution where this is not required and the gradle plugin in artifactory is available without buildscript{} – Sundeep Gupta Jul 12 '14 at 05:09
  • Then probably the solution #2 (and maybe the @VonC's one) is the best for your case. Likely changes to the script will be infrequent, so users won't have to update each five minutes. – user3159253 Jul 12 '14 at 13:55
3

Assuming the Git repository is accessible over HTTP(S), one option is to use apply from: "http://...". Note that script plugins accessed over HTTP aren't currently cached, so the build will fail if the script cannot be fetched.

Peter Niederwieser
  • 121,412
  • 21
  • 324
  • 259