如何在Jenkins中无需克隆的情况下监听子模块更改

Question

Jenkins is on a detached head. Whenever a submodule gets updated, I need to trigger a build. However, only the main project gets cloned.

Two questions

• How do I tell Jenkins to trigger a build when a submodule gets updated, but not clone the submodule? I need the main project code cloned instead, but Jenkins still needs to start the build only when the submodule gets updated. So let's say say submodule A gets updated (a new commit ism adE), it should trigger a build where the main project code gets cloned. The submodule is not cloned.
• How do I pull the latest changes from the submodule to the submodule directory after Jenkins clones the main project? Granted, the submodule directory will be at a detached head. How do I pull the latest changes to the submodule from the most recent commit (I cannot use git submodule update because that does not pull the latest changes to the submodule).

Basically, I want to give each submodule its own CI environment for testing, but each submodule is not a standalone application; they depend on the main project. So when a submodule gets updated, we need the main project updated with the latest code from that submodule without having the submodule cloned, the code from the submodule must be pulled. I don't want to set the polling on the main project. Jenkins should be checking the submodule each time to check if there is a new commit

Answer 1

I would recommend one Jenkins job monitoring the parent repo.

By default, it doesn't clone the submodules if you don't enable Job Configuration -> Section Source Code Management, Git -> Advanced Button (under Branches to build) -> Recursively update submodules .
It will just monitor a clone of the parent repo, to fetch the latest commits at regular interval, simply by enabling Poll SCM, not by setting specifying a schedule: see " Automatically triggering a Jenkins build on Git commit ".

If a submodule is updated, that means the parent repo will change as well.
When a submodule changes, a new parent repo SHA1 will be created and pushed as well, recording a gitlink (a special entry in the index ). That gitlink references the new SHA1 of the submodule.

That means, each time the parent repo changes, the jenkins job needs to do a:

git diff --name-only --diff-filter=M ${revision} HEAD

If the M (modified) list include the right submodule for that job, then (using a Parameterized Trigger Plugin ), trigger the right CI job.

The right CI job (one per submodule) will also monitor the main parent repo, will also not clone the submodules by default, except for the right one.
Its first step should follow " git submodule update specific submodule only "

git submodule update --init -- <specific relative path to submodule>

The rest of the job can build/test that specific submodule.