Make it clearer how to prevent triggering for SCM materials shared between pipelines

[chadlwilson]

Issue Type

• Feature enhancement

Summary

As discussed in #9858, the configuration of materials can be a bit confusing where you want to

• Git repos Client1 and Client2
• Pipeline A1 produces build artifacts from Client1
• Pipeline A2 produces build artifacts from Client2
• Pipeline B1 has pipeline A1 as a material, and a git material called PublishScripts.
• Pipeline B2 has pipeline A2 as a material, and a git material called PublishScripts

The intent is only for commits and dependent pipeline triggers of B1 and B2 to cause builds, not for commits to the PublishScripts repo.

Intuitively, users will select "do not poll" on the PublishScripts git repo. This works most of the time, however if you manually trigger a build of B1, the PublishScripts material will be updated and it will also trigger a build of B2, which is not intended. This would also apply if you used a webhook trigger to notify GoCD of an update to PublishScripts

By triggering the manual start you are triggering a "manual check" of the material to find its latest revision. At that point GoCD says "well, this wasn't a scheduled poll, and I have new information about this repo/branch's latest revision, so I should still check which pipelines are dependent on this material and trigger them if their allow/denylists say it should".

The workaround for this is to instead use blanket denylists (**/*) on the pipeline material configuration for B1 and B2 since this is the true inbuilt mechanism for preventing triggering. However this is a little opaque.

Basic environment details

GoCD 21.3.0 and earlier

Additional Environment Details

Steps to Reproduce

In the earlier example with Client1, pipelines A1, B1, Client 2, A2, B2... etc...

1. In a stable gocd environment where nothing is running or scheduled
2. Commit changes to PublishScripts
3. Observe nothing is scheduled
4. Manually run pipeline B1.
5. B1 is scheduled as you'd expect via manual action
6. Observe pipeline B2 is also scheduled

Possible Fix

• In YAML config, the setting for disabling polling is just called auto_update without significant documentation.
• For pipeline materials there is a different setting "Do not schedule the pipeline when this material is updated" (aka ignoreForScheduling which has clearer naming, but is not supported by SCM materials.

We could

• document better how to use denylists to achieve this goal in UI and or the yaml plugin
• introduce ignoreForScheduling to SCM materials
  • this seems to be a specific case of the more generic use of denylists, however
• introduce UI-only magic which sets denylists appropriately to make ignoreForScheduling work.
  • this would have the disadvantage of providing no support for pipelines-as-code

Code snippets/Screenshots

GoCD itself uses the denylist approach for its codesigning as discussed here.

[christabone]

Just wanted to chime in here really briefly.

I read through the earlier discussion and followed the link to the issue here. This is probably the most common "trip-up" we experience when working with our pipelines. We have this use case in probably ~5 or 6 instances, at least, and new devs always get thrown for a loop if they don't know the **/* trick.

I would love a more obvious solution for this issue, like the suggested UI change with a slider. Just my $0.02. Thanks!