How to always checkout latest revision?

[paunovic]

Hello, we have microservice monorepo and have noticed that plugin checks out latest git revision that only touched paths that plugin monitors. We have one material per service, and each material monitors on its service subpath. When some service is about to be built & deployed, plugin picks up latest commit that touched the service. This is problematic as we want build phase to always checkout latest revision from master instead, as there are indirect dependencies between microservices. Is there a way to enforce plugin to do this for build phase?

[chadlwilson]

Unfortunately, that would defeat the purpose of this plugin, and the thing that makes it distinct from the built in git material of GoCD.

I you want the behaviour you describe, you may be better to use the built-in Git material, with allowlists/denylists. The built in material performs in basically the way you are describing (if it triggers whether automatic|manual, it always checks out latest revision for the entire repo - including paths that are not strictly relevant from allowlist/denylist).

The downside of the way the built-in Git material behaves are described in the intro but include that

• it often blocks fan-in, because the "revisions" it triggers with are sometimes for revisions unrelated to the monitored subpaths and can lead to inconsistent "material revisions" and "triggered builds". If you are not relying on fan-in, this may not be a problem for you.
• the changelog/modifications include unrelated changes

Your choices are basically

• add all relevant paths for indirect dependencies to the expression in the git path material
• switch to the built-in Git material where allow lists/deny lists are not considered in the material revision and are only considered for "should I trigger a run?"

The key thing to understand is that for GoCD, upstream revisions and triggering of upstream builds are critical for considering whether a fan-in trigger can happen for a downstream pipeline. The key difference with this plugin is that it directly ensures that material revisions GoCD is aware of are always consistent with triggering conditions, since the filtering is done at the git level, and the filtered paths are used to evaluate whether two materials are logically distinct.