So the RHEL platform_family target is a bit of a jumble, so I wanted to see if anyone had any thoughts on the best way to structure how we build the ruby runtime to best account for that.
Note: transitioning Sensu assets to golang nicely avoids the complexity of linux distribution models when it comes to Ruby based Sensu assets. So please, if your looking at extending Sensu with a new plugin and want to share it as an asset via Bonsai, take a look at the Sensu plugin SDK
Okay with that out of the way, let’s first talk about the Ruby runtime asset.
First: Ruby runtime on Amazon Linux, which self-identifies as a rhel platform_family member.
In December I added Amazon Linux and Amazon Linux 2 build targets to the sensu-ruby-runtime asset as a prerequisite to start updating other ruby based assets with similar builds.
Its not clear how divergent Amazon Linux is from rhel6 or how Amazon Linux 2 is from rhel7. These are definitely not strict rebuilds or rhel sources, so it seems reasonable to add it as a build target.
Moving forward, individual ruby assets will need to be updated with matching builds and asset build filter rules. It’s a little cumbersome because the filter rules have to now separate out rhel/centos from amazon. We may want to rethink the approach to this and automate more of the build filter construction so it always matches the builds the target ruby-runtime asset supports. Anyone have any thoughts on this?
Second, I’m looking to transition the ruby-runtime to use rhel build targets (like the ubi images) instead of CentOS build targets for the non-Amazon build. Anyone interested in helping put that change into practice?