Job update fails with error (Exec[reload-jenkins] not in catalog)

[ofalk]

Hi!

I pulled the latest source today and now I get the following error:

"""
Could not retrieve catalog from remote server: Error 400 on SERVER: Invalid relationship: Exec[jenkins update-job puppet] { notify => Exec[reload-jenkins] }, because Exec[reload-jenkins] doesn't seem to be in the catalog
"""

A bug or a misconfiguration on my side?

[jhoblitt]

This is likely a regression caused by: 979cb01 Do you have class { 'jenkins': cli => false }`?

[ofalk]

I have no ::cli stuff defined at all :-/
Shall I try to define it? Earliest tomorrow...

[ofalk]

Adding cli => true to my jenkins class resolved the error!
So maybe you want to add this as a default and not allow disabling it!?

[jhoblitt]

I suspect that jenkins::cli needs to include jenkins::cli::reload to fix the regression. I'll need to do some testing to make sure that doesn't reintroduce the dependency loop for jenkins::cli::exec that commit resolved.

[nand0p]

this change broke my CD. fix for cfn-init:"sed -i 's|include\\ jenkins::cli\\|include\\ jenkins::cli\\ninclude\\ jenkins::cli::reload|' /etc/puppet/modules/jenkins/manifests/job/present.pp" .... yeah so this is a bad fix just pin at 1.3.0

[jhoblitt]

@ofalk / @nand0p It turns out there are multiple issues here.

1. This module implements "the anchor" pattern for resource ordering which is not enabled for usage of the "cli" unless class { 'jenkins': cli => true }. As the module is currently designed, it should really disallow the usage of any class/define that uses the cli. We need to try to support the defacto API but a breaking change will likely be needed to fix this properly.
2. Even if cli => true, the defined types are not safely ordered nor are they contained by the Anchor[jenkins::end] resource.
3. Due to \1, none of the unit tests inspect resource ordering.
4. There are no acceptance tests that cover any of the defined types.

I have attempted to fix the inclusion problem reported in this issue, fix \2 which I just described, and add a simple acceptance test for jenkins::job. That later appears to be non-idempotent with jenkins 1.1613.

It would be fantastic if either of you would be willing to contribute acceptance tests for the other interface classes and types.

@rtyler #298 should fix this issue, so there's likely some urgency to get a patch release out, but I'd advise careful review for fear of introducing new ordering problems.

[jhoblitt]

#298 has been merged -- is this issue still present?