I often find myself wanting to write a katello UI plugin but groaning at the thought of copying an existing one and sed/awk'ing it into shape. So this time, I decided to do it right and create a "best practice" sample bastion plugin[1]. (I am trying to follow along in the foreman wiki plugin writing guide too.)
I want to keep it fairly minimal but have enough there to set up all the infrastructure needed. This includes things like apipie, permissions, rubocop, etc. The README has a running list of things I'm trying to include.
Part of this excercise is also to get back to understanding the basics. It's easy to take rubocop for granted, for example, instead of actually wiring it up to test PRs. I plan on making wiki pages in this repo describing the various aspects which should help new devs understand various aspects of the tooling.
Along with this functional sample plugin, I am adding a plugin generator[2] that will allow anyone to run 'yo bastion:plugin' and create this sample with everything named correctly.
Although right now the sample relies on some katello classes, I do want to eliminate that so it works on core foreman. (I had problems getting scoped search to work with the foreman api base controller, for example, so switched to using katello's.)
If anyone cares to contribute, please do. I'd especially welcome comments on where I go astray of what we'd consider best practice. Thanks to @ehelms and @daviddavis for helping on this after-hours project.
[1] https://github.com/thomasmckay/sample-bastion-plugin
[2] https://github.com/Katello/generator-bastion/pull/6
···
--
@thomasmckay
Putting this on hold until we settle on UI infrastructure.
···
----- Original Message -----
>
> I often find myself wanting to write a katello UI plugin but groaning at the
> thought of copying an existing one and sed/awk'ing it into shape. So this
> time, I decided to do it right and create a "best practice" sample bastion
> plugin[1]. (I am trying to follow along in the foreman wiki plugin writing
> guide too.)
>
> I want to keep it fairly minimal but have enough there to set up all the
> infrastructure needed. This includes things like apipie, permissions,
> rubocop, etc. The README has a running list of things I'm trying to include.
>
> Part of this excercise is also to get back to understanding the basics. It's
> easy to take rubocop for granted, for example, instead of actually wiring it
> up to test PRs. I plan on making wiki pages in this repo describing the
> various aspects which should help new devs understand various aspects of the
> tooling.
>
> Along with this functional sample plugin, I am adding a plugin generator[2]
> that will allow anyone to run 'yo bastion:plugin' and create this sample
> with everything named correctly.
>
> Although right now the sample relies on some katello classes, I do want to
> eliminate that so it works on core foreman. (I had problems getting scoped
> search to work with the foreman api base controller, for example, so
> switched to using katello's.)
>
> If anyone cares to contribute, please do. I'd especially welcome comments on
> where I go astray of what we'd consider best practice. Thanks to @ehelms and
> @daviddavis for helping on this after-hours project.
>
>
> [1] https://github.com/thomasmckay/sample-bastion-plugin
> [2] https://github.com/Katello/generator-bastion/pull/6
>
> --
>
> @thomasmckay
>
> --
> You received this message because you are subscribed to the Google Groups
> "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to foreman-dev+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
