Conditional routes and bot name in Lita - ruby

I am trying to develop a simple Lita chat bot with more flexible command routing.
There are a couple of issues I am having difficulties with.
1. Conditional routing
How can I use config values before or inside route definitions?
For example, instead of this definition that needs a "run" prefix:
route(/^\s*run\s+(\S*)\s*(.*)$/, :cmd, command: true)
I would like to use something like this, with a flexible, config-based prefix:
route(/^\s*#{config.prefix}\s+(\S*)\s*(.*)$/, :cmd, command: true)
Which fails. So I also tried something like this:
if config.use_prefix
route(/^\s*run\s+(\S*)\s*(.*)$/, :cmd, command: true)
else
route(/^\s*(\S*)\s*(.*)$/, :cmd, command: true)
end
Which also fails with a not very helpful error.
In both cases, I defined the proper config key with config :prefix and config :use_prefix.
2. Showing the bot name in the help
I know there is a robot.name property available for me inside the executed command, but I was unable to use it inside of the help string. I was trying to achieve something like this:
route(/^\s*run\s+(\S*)\s*(.*)$/, :cmd, command: true, help: {
"run SCRIPT" => "run the specified SCRIPT. use `#{robot.name} run list` for a list of available scripts."
})
but it just printed something unexpected.
Any help is appreciated.

The issue is that you're confusing the config class method and the config instance method. config at the class level (code in the class body but not inside an instance method definition) defines a new configuration attribute for the plugin. config at the instance level (inside an instance method or in an inline callback provided to route using a block) accesses the values of the plugin's own configuration at runtime.
In the current version of Lita, there isn't a pretty way to use runtime configuration in class-level definitions like chat routes. The workaround I've used myself is to register an event listener for the :loaded event, which triggers when the Lita::Robot has been initialized. At this point, configuration has been finalized, and you can use it to define more routes.
For example:
class MyHandler < Lita::Handler
on :loaded, :define_dynamic_routes
def define_dynamic_routes(payload)
if config.some_setting
self.class.route(/foo/, :callback)
else
self.class.route(/bar/, :callback)
end
end
end
You can look at the code for lita-karma for a more detailed example, as it uses this pattern.
The next major version of Lita is going to include an overhaul to the plugin system which will make this pattern much easier. For now, this is what I'd recommend, though.

Related

Can I tell pylint about a specific param a decorator requires and have it not apply unused-argument?

I use pyinvoke which has a task decorator that works like this:
#task
def mycommand(
# MUST include context param even if its not used
ctx: Context
):
# Do stuff, but don't use ctx
Even if I don't use ctx I must include it for pyinvoke to work correctly. Pylint throws Unused argument 'ctx' Pylint(W0613:unused-argument).
From what I have read in GitHub issues it seems like it would be unreasonable to expect pylint to dig into decorators and figure them all out automatically.
I also don't want to turn off this pylint rule for the entire function.
Is there a way I can tell pylint that if the #task decorator is used do not apply the W0613 rule to the first argument of the function?
When there is code that is too dynamic and impossible to parse for pylint it's possible to create a "brain" i.e. a simpler version that will explain what the code does to astroid (the internal code representation of pylint). Generally this is what a pylint plugin does (for example pylint-django will do it for view function that need request, which is similar to your issue with ctx). Here's an example of brain for signal directly in astroid and the documentation. It's possible that a pylint plugin already exists so you don't have to do this yourself.

Nesting custom resources in chef

I am trying to build a custom resource which would in turn use another of my custom resource as part of its action. The pseudo-code would look something like this
customResource A
property component_id String
action: doSomething do
component_id = 1 if component_id.nil?
node.default[component_details][component_id] = ''
customResource_b "Get me component details" do
comp_id component_id
action :get_component_details
end
Chef::log.info("See the output computed by my customResourceB")
Chef::log.info(node[component_details][component_id])
end
Thing to note:
1. The role of customResource_b is to make a PS call to a REST web service and store the JSON result in node[component_details][component_id] overriding its value. I am creating this attribute node on this resource since I know it will be used later one, hence avoiding compile time issues.
Issues I am facing:
1. When testing a simple recipe that calls this resource in chef-client, the code in the resource gets executed to the last log line and after that the call to customResource_b is made. Which is something I am not expecting to happen.
Any advice would be appreciated. I am also quite new to Chef so any design improvements are also welcome
there is no need to nest chef resources, rather use chef idompotance, guards and notification.
and as usualy, you can always use a condition to decide which cookbook\recipe to run.

RuboCop Error - Define a global variable in Cucumber RUBY files

I need to define a global variable in my Cucumber env.rb file which can be accessed throughout the framework in all step methods. Currently i am defining as this in my env.rb file:
$global_var ||= false
And i need to access this var into the Before hook as well After hook and few step methods where i am re-initializing this. It is working perfectly as i want. But the problem is, rubocop doesn't like this and throwing error as "do not use global variable". How can i resolve this ???
FYI, I tried using singleton to define this var as accessor and not quite sure where i am missing.
Change the config file for rubocop. use the link:
Example to Change
Look for the passage starting with When we look in the .rubocop_todo.yml file we see something like this: and also Configure Rubocop to be your style guide
Link to List of Configuration Changes possible:
Link to List of Styles
change .rubocop.yml file:
Style To Change:
GlobalVars: Enabled: false
Example File : Example file - how it looks like
How to Configure Style: Style/Inheritance Guide

How can I call a Chef resource from an HWRP?

Maybe this is really simple, and I'm just not understanding something. I want to invoke a Chef resource from within an HWRP that I wrote. In my scenario, I'd like to invoke the reboot resource. How should I go about doing so?
I have tried something like the following:
def reboot_system
wu_reboot = Chef::Resource::Reboot.new('wu_reboot', :reboot_now)
wu_reboot.run_action(:reboot_now)
end
A few things. I am not sure if I should be creating an instance of Chef::Resource::Reboot or Chef::Provider::Reboot. I also don't really understand the second argument listed above..this is supposed to be the "run_context", but I don't know what that is. Finally, I do not know how to set attributes or invoke an action.
I tried using this as a format to go by, but I haven't been able to get it to work so far. Any help understanding would be much appreciated.
EDIT:
I looked at the source code and I could just execute this:
node.run_context.request_reboot(
:delay_mins => #new_resource.delay_mins,
:reason => #new_resource.reason,
:timestamp => Time.now,
:requested_by => #new_resource.name
)
However, I don't think this is the best solution. I would like to know how to accomplish invoking the resource instead of bypassing it this way.
You can find an example of using Chef-Resources inside a HWRP in an older revision of the official Jenkins cookbook (was converted to LWRP in the meantime):
https://github.com/opscode-cookbooks/jenkins/blob/v2.0.2/libraries/plugin.rb#L138-L141
Keep in mind, that the Reboot resource is rather new (Chef 12+)
You can do it the same way you would in a recipe. If you need it to run immediately, then you would do:
reboot 'now' do
action :nothing
end.run_action(:reboot_now)
Within Ruby classes, you don't have access to the Chef DSL, so you have to access the underlying implementation of the resource as a class. The name of the class will be the camelcase-conversion of the resource name. You invoke the action with the run_action method.
Your original version actually was pretty close. You only use the resource, not the provider (because the provider may not even always be the same, depending on your platform).
The run_context is an object that chef uses to pass information to the resource - for instance, you can access node attributes through run_context.node['attributename']. It is already a member variable in your provider (and I think also in the resource object); you can simply pass it in to the constructor for your new resource.
You set attributes through member variables by the same name, and you trigger the actual action with the run_action method.
r = Chef::Resource::Reboot.new("wu_reboot", run_context)
r.reason("Because we need a reboot")
r.run_action(:reboot_now)

Passing values from Capistrano deploy.rb file to app

In my Capistrano's deploy.rb file, I set up different environments such as server names, ports, etc. I also require the users to send a callback to another server, also defined in the deploy.rb. How do I cleanly pass this value to my app?
Something to this effect:
config/deploy.rb:
set :callback_url, "http://somecallbackurl.com:12345/bla"
app/controllers/myapp.rb:
def get_callback_url
???
end
I'm using Sinatra.
I found a solution, and that is to use the environment variables.
Set it from deploy.rb
run "export CALLBACK_URL=#{callback_url}"
From app:
def get_callback_url
ENV['CALLBACK_URL']
end
I wouldn't say it's the cleanest solution, but it works.
I'd probably recommend using a shared YAML file to store this kind of configuration, and loading it separately. For example, have a file named something like config/settings.yml, containing something like:
:callback_url: "http://somecallbackurl.com:12345/bla"
In config/deploy.rb, you could have:
settings = YAML.load_file('config/settings.yml')
set :callback_url, settings[:callback_url]
And in config/initializers/settings.rb, you could have:
settings = YAML.load_file('config/settings.yml')
CALLBACK_URL = settings[:callback_url]
Finally, in app/controllers/myapp.rb, you would do:
def get_callback_url
CALLBACK_URL
end
Using a shared YAML file is just the first thing I thought of. Another approach would be defining some constants in a ruby file, and requiring that file both in an initializer, and in deploy.rb. The basic idea is that you don't really want your app to depend on your capistrano environment, so you should find a way to separate the shared configuration.

Resources