10

We just migrated to Git, so if I ask stupid questions, please forgive me :-)

Our Git repo contains several Maven projects, like this

ssh://git@git.whatever.com:7999/foo/foo.git
   bar1
   bar2

I have separate Jenkins jobs to build bar1 and bar2. To prevent that a push to bar1 also triggers bar2, I configured the Git plugin in bar2 under Advanced... Included Regions to include only bar2/.* - and vice versa in the bar1 job: bar1/.*

This works well, but there's one thing that nags me: The changes within both jobs show all the changes of the repo (bar1 and bar2) instead of just the changes of the specific project.

How can I configure that?

Screenshot: enter image description here

eerriicc
  • 1,124
  • 4
  • 17
  • 29
  • Do you use a repo for each one (i.e. bar1 in its own repo and bar2 in its own repo) or are they both in the same repo (im assuming the later, but you said repos which is plural, so im confused). – Lee Sep 04 '13 at 08:45
  • Yes, both bar1 and bar2 are in the same repo foo. Sorry if that was unclear, I changed the question. – eerriicc Sep 04 '13 at 10:59
  • Thought that might be what you meant, got half way through writing my answer below before realising and thought i'd check before posting an answer. – Lee Sep 04 '13 at 13:21
  • how do you configure your jobs to do "just" bar1/bar2 here? like this?http://stackoverflow.com/questions/17310959/is-there-any-way-to-change-the-working-directory-of-a-jenkins-maven-build – rogerdpack Mar 19 '14 at 22:41
  • Well, the first thing is that (using a Maven project) I specify that the root POM is in bar1/pom.xml. The second thing is that I configure the Git plugin only to react to changes in the bar1 directory. For this I click on the Advanced... button in "Branches to build" and specify the path to react to: Included regions: bar1/.* – eerriicc Mar 20 '14 at 08:46
  • I don't find that options "regions" can you paste a screenshot ? – Nathan Redblur Apr 06 '17 at 18:55
  • OK, added a screenshot – eerriicc Apr 07 '17 at 11:42

2 Answers2

0

Very late, but Jenkins always checks out the entire repo (even when doing sparse checkouts, Jenkins still clones the entire repo to local disk) and shows the revision of the repo as a whole on the build page.

This was intended by the Jenkins developers. A core aspect of CI is being able to easily track changes across the history of a repo. Change tracking across a repo would become very difficult (and near impossible with large repos) if only the revision of a subdirectory was shown for each build.

Stew C
  • 697
  • 3
  • 10
  • 24
-1

I'm assuming you mean the commit log when you refer to changes, in which case you cannot do what you require without a custom git client or at least a custom git commit viewer script.

A single repository should in theory only ever contain one project. Otherwise you are using git "wrong" (using the word "wrong" in a very loose sense as git is just a tool, using it wrong is impossible, there's just using it badly for your own requirements).

The only way to do what you want is to split the bar1 and bar2 folders into separate git repo's. If they are a bit like modules, which are both required on the same site, you could git init/clone into the bar1 and bar2 folders respectively for each project so you can control them separately.

Another alternative would be to separate them out into separate git repo's, then create a third "master" repo which just includes the two other repo's as sub-modules inside their respective folders. Then use a custom git hook as you probably already do, to make the master pull and build the correct folder/project/bar(x) . However this is a bit of a hacky way of doing things purely for the sake of not having to set up a few folders first.

Basically put, you can't split out the commit log based on the folder, without writing your own custom commit viewer. You need to separate the project into multiple repo's. How you then bring them back to together and automate any build tasks, is up to you. There's no doubt more ways that the ones i mention above. Just a case of finding the best solution for your needs.

Lee
  • 10,496
  • 4
  • 37
  • 45
  • Unfortunately, the decision was already made to integrate several projects into one repo. But thanks for your answer! – eerriicc Sep 05 '13 at 07:44
  • 14
    Google has literally tens of thousands of projects in a single (Perforce) repo. Facebook does the same with git. If you decide to tell them they are doing it "wrong", **you might as well let Torvalds know too,** as [git itself](https://github.com/git/git) has multiple projects (in the sense that they are *built*, *packaged*, and *deployed* separately): git, gitk, git-gui, gitweb. – Paul Draper Mar 23 '15 at 02:56
  • @PaulDraper Your reply contains so many misrepresentations of my answer, it not even worth breaking it down to reply. You also might want to fact check your statements too. – Lee Mar 23 '15 at 20:18
  • 1
    @Lee, the answer is confusing. while pushing project from eclipse it creates subdirectory, the other option is not recommended. Means subdirectory in git hub is recommended though integration with jenkins is difficult. – Shamseer Mar 31 '16 at 22:24
  • @Shamseer Either do what eclipse recommends, or don't. Read the eclipse docs on why they recommend it, if you agree, go with it, if not, then don't. – Lee Apr 02 '16 at 14:41
  • 5
    Paul Draper's comment is exactly correct. Google has 2 *billion* lines of code in a single repo, and within the uber repo they have many separate projects. Mapping one project to one repo works for toy systems, but quickly encounters the diamond problem, and founders on a lack of atomic commit/rollback. – Jim Showalter Nov 27 '16 at 23:10
  • 3
    @user1461450 I never said it wasn't. But the guy isn't running Google. There's pro's and con's to fat and slim repo's and i've seen more companies get into a mess with fat repo's due to a lack of understanding the trade-offs. Slim repo's are a safe way to organise code until you have the knowledge and resources to make an informed decision. I made it clear that the use of the word "wrong" was in terms of "wrong for your requirements" which seems to be overlooked by everyone in their quest to show off their wikipedia skills. – Lee Nov 28 '16 at 13:23