Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

miqbot CLI #499

Open
NickLaMuro opened this issue May 7, 2020 · 6 comments
Open

miqbot CLI #499

NickLaMuro opened this issue May 7, 2020 · 6 comments

Comments

@NickLaMuro
Copy link
Member

It would be nice for developers to be able to run the same linters that the bot does from their own machine via a miqbot CLI command, or some other form.

Some considerations:

  • Making it a gem would allow for an easy install, but I think based on some issues with including it in a bundle, it is preferred to have it as a separate install. We could probably just add a miqbot.gemspec that pulls only what we need from the lib/ dir to make this happen.
  • Might want to make some changes to the worker classes so that the same code paths they call into are what is being called in via the CLI. I don't for see this being a lot of work, just want to make sure that we are supplying methods for the classes in lib with non-activerecord objects and only the service objects as input. This might already be the case, but I would have to check.
  • The "public configs" notion on [RFE] Use config/settings* for configuring "secrets", but not "configs" #486 would be relevant for this if there is anything that is "config specific" that we would want developers to have when running locally. Not sure there is, but would have to check.
  • pronto is already CLI based, and there was an effort a while back to make use of this instead of our custom code (see Pronto integration #406, GitHub Status API Integration #412, and Miq-Bot's Pronto Formatter #424 for details). This probably wouldn't replace the need for a custom miqbot command, but it would greatly simplify the glue needed for that, and we probably could just inherit a lot of things from that project for our implementation.
@Fryguy
Copy link
Member

Fryguy commented May 7, 2020

Yeah I was thinking that maybe we get pronto over the finish line, and then like you said just inherit a lot from that.

I wonder if our "custom" commit checking stuff can also just be more linter entries under pronto or rubocop.

@NickLaMuro
Copy link
Member Author

Possibly. I would have to do some research on what we have already attempted with the pronto effort (and pronto in general), but that would be nice.

@Fryguy
Copy link
Member

Fryguy commented May 7, 2020

Really like this idea overall...would be cool to be able to run the guts of the bot locally. I have to wrap my head around it a bit more. I'm wondering if it makes sense to extraact the guts into a separate gem with the bin/cli and the actual pieces of work, then miq_bot the "Rails app" takes care of the database, sidekiq, and calling into the library.

@NickLaMuro
Copy link
Member Author

Yeah, I was considering the gem library bit myself. The approach I was considering was just "one gem" to avoid needing a "lib gem" and a "cli gem".

However, I guess if the rails app consumed the miqbot cli gem, that is effectively one gem as well.

¯\(°_o)/¯

@skateman
Copy link
Member

skateman commented May 7, 2020

❤️ for pronto

@miq-bot
Copy link
Member

miq-bot commented Mar 6, 2023

This issue has been automatically marked as stale because it has not been updated for at least 3 months.

If you can still reproduce this issue on the current release or on master, please reply with all of the information you have about it in order to keep the issue open.

Thank you for all your contributions! More information about the ManageIQ triage process can be found in the triage process documentation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants