Apply gradle file from different repository

Solution 1:

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".

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

Solution 2:

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

Solution 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.