I am attempting to get a plugin from the old sensu plugin library (https://github.com/sensu-plugins) – specifically sensu-plugins-openldap – to work as an asset. Here’s what I have tried.
I’ve hosted a copy of the sensu-plugins-openldap repo on my company’s bitbucket server, and sensu has no problem pulling it down in tarball format and treating it like an asset – it arrives on the target host in /var/cache/sensu quite fine.
However, I get the dreaded dependency error, “cannot load such file – sensu-plugin/check/cli (LoadError)”. So it can’t find sensu-plugin.
The thing is – sensu-plugins-openldap is using EXACTLY the same template as several other sensu plugins that live in Bonsai. All the same directory structures and files are there, so I know it should be raking/bundling/setting paths in the same manner as these other assets, which work fine.
sensu-plugin is defined in the gemspec in exactly the same manner as, say, sensu-plugins-cpu, which I use as an example (though it’s an old version, which I have updated in my fork).
sensu-plugins-cpu-checks works just fine. It arrives on the target host just fine. It’s got sensu-plugin defined in its gemspect, just as sensu-plugins-openldap. In fact, I can find almost ZERO differences between the code in either of these, except for tiny things such as one rakefile treats paths as a hash, and the other as a list:
But I’ve changed these tiny differences and no dice. So I still can’t see what makes one of these assets able to find sensu-plugins and not the other. I’ve been crawling through the docs and forum posts looking for some piece that I’ve been missing, but so far I’m not finding anything.
Thanks Todd. I’ll be really interested in what you find that you need to change to make it ‘asset-able’, and I’d really like to understand what the issue is here, since I have several other plugins that I’d like to use as well as we move all of our checks from sensu classic to go.
The asset is on Bonsai now. The big thing is around generating the gem including the latest version of the sensu-plugin dependency. If you review the commits I made, most of what you will see is my updating a few of the other dependencies and getting rubocop to pass so that the Travis builds will succeed.
As for the other plugins you may need, if you can provide a list we can see about getting the rest of them into Bonsai.
Yeah I’m not sure what you were doing in your private build, but I’m interested if you could document it so I can re-test. It would be nice to have a reliable pattern for private asset building.
My best guess,without seeing the build logic in your private repo, is your building against a different ruby environment than what the sensu-ruby-runtime Docker images provide, so as a result, when you try to build assets are you doing something subtly wrong that is breaking the gem finding logic.
The basic build pattern being used in the sensu-plugins repository is in https://github.com/sensu/sensu-go-bonsai-asset . You can see how its used in the .travis.yml files in the sensu-plugins with assets.
Following that build logic in the Dockerfiles in the helper repository, the asset tarball’s bin/ directory is populated with bundle binstub scripts. These mimic how bundle exec works. These bundle binstub scripts are essential magic. My best guess is your build process isn’t using them and you are just doing a gem install.