I have configured my trigger restrictions as explained in the documentation, but the jobs are not working as expected and I do not know why.
According to the documentation, the Trigger Restrictions Plugin, allows you to control the source of the jobs triggering other jobs in different level of your instance.
There is a general configuration which is placed at global level, which sets the trigger restrictions existing for every single job inside that instance. This configuration is shown in the documentation mentioned above.
Later on, we can define additional restrictions at Folder level that can act overriding the existing restrictions (coming from the global configuration or from parent folders).
The key element to understand how trigger restrictions plugin works is to understand that the plugin performs a consistency check which essentially verifies that any given child restriction is at least, as restrictive as its parent.
Thus, one potential cause for your triggering restrictions not working as expected is related to the above mentioned consistency check. Let’s consider an example where you start configuring the triggering restrictions for your controller, and you leave empty the Default trigger restrictions. This does not mean that you are not setting any restriction, on the contrary, this means that you are not allowing anything to trigger jobs existing in your controller as the list includes the potential sources for upstream jobs. As you left it blank, no upstream jobs will be allowed to trigger jobs in your controller.
What does this mean? This means that if you set a trigger restriction in a folder of your instance, overriding the existing triggering restrictions, it will not be applied as it will be less restrictive than the parent restrictions (set at controller level, for example).
But, how can you know that you made such mistake? The only visible symptom of a problem is the fact that when you try to trigger your jobs satisfying the restrictions configured you get one of the following results depending on the upstream job’s nature:
If the upstream job is a Pipeline, the step will fail and your build will break.
If the upstream job is a Freestyle job, the upstream job will run and even if the build status is compatible with your configuration in the post-build step to trigger the downstream job nothing will happen.
The key element here are the Jenkins logs. When you experience a case like the one shown above, you will see in the logs traces like the ones shown below:
WARNING: Trigger restrictions inconsistency found. [XXX/Subfolder] restrictions configuration is less restrictive than its parent/ancestor [XXX]