One of the benefits writing your bots in Bubblescript is the fact that you can reuse code in different dialogs. With Skills, you can reuse parts of one bot, within another bot. Skills can therefore be thought of as a tool that you can buy. Programmers can think of Skills as libraries or packages. A skill can depend on other skills, just as a drill can depend on a drill-bit to perform its function.
DialoX provides a few internally developed skills for you, but of course you can create skills yourself. At the moment, it is not possible to publish skills for other people to install, but this is a planned functionality for the future.
Installing an external Skill¶
Skills provided by DialoX can be installed through the Skills main-menu item. On the underlying page, you can find an overview of skills that are available and the skills that are already installed in your bot. A skill is installed using the "Install" button in the pop-up.
All the dependencies for a skill will be installed automatically.
Configuring a Skill¶
Once a skill is installed, it can, depending on the skill, be configured to perform its task in a way you desire. Configuration of the Skill is done in the "Installed" section by clicking on the cogwheel of a Skill.
Uninstalling a Skill¶
Skills can be uninstalled in the "Installed Skills" by clicking on a Skill and then on the "Uninstall Skill" button. If the Skill you are trying to uninstall has another installed Skill that depends on it, an error will be shown with the name(s) of the Skill(s) that depend on it. Uninstall those skills first.
Disabling a skill¶
Skills can be temporarily disabled. This functionality can be used to first install the skill and then configure it, without exposing the skill yet to the world.
A skill exists in its own folder in the bot, where all the files that are necessary for the Skill to function properly are stored. Subfolders can be used to create a more structured hierarchy if needed.
The information about the Skill is stored in the
that resides in the directory of the Skill. This file has the
following fields that describe the skill:
string, mandatory, unique identifier of the Skill,
string, mandatory, a display title for the Skill,
string, mandatory, the icon that is displayed in the Skills section (blueprintjs icon),
string, mandatory, a small description of what the Skill does.
list of string, a list of names of other Skills that this Skill depends on,
list of string, a list of names of other Skills that need to be ordered below this skill,
string, the license that the skill is published under,
list of images, screenshots of the Skill,
settings schema, a CMS definition of the settings for this Skill,
list of strings, a list of tags that apply to this Skill,
string, a semantic version of the Skill at the time of publishing.
A minimal skill.yaml file:
name: "company/skill" title: "My Skill" subtitle: "Provides basic behaviour" icon: "badge" version: "1.0.0" dependencies: - "bsqd/base"
And a skill which defines a settings screen:
name: "company/skill" title: "My Skill" subtitle: "Provides basic behaviour" icon: "badge" version: "1.0.0" settings: type: form storage: type: script script_title: config/company_skill title: Users icon: people form: schema: type: object properties: name: title: "A configurable string field" type: string
Often you develop multiple skills inside a single bot. In that case, you might want to write test cases that only cover a single skill. In such cases, it is best to disable the other skills in the bot that are not the focus of the current test.
It is possible to automatically disable certain skills for certain test files,
by setting the
@disabled_skills constant in the test file, like this:
@disabled_skills ["b"] test "Only testing skill a" expect "Hello from a" end
Sometimes it can be necessary to run code when a skill upgrades its version, or
when it is installed. For this purpose, skill migrations exist. Migrations are
tasks, which live within the folder of the skill, which are annotated with a
Skill upgrade migrations¶
When a skill is upgraded, the following happens:
- The source version of the skill is retrieved; this is the currently published version number of the skill;
- The target version of the skill is retrieved from the skill in the store;
- From the skill's scripts, all tasks are gathered which have a
migrate_toattribute with a version number which lies between the source and the target version
- These tasks, ordered by their version number, are then performed in the bot.
log statements in the tasks are collected and presented to the developer
afterwards. When a migration task fails, the upgrade of the skill is cancelled.
An error can be raised from within a task by using the
write_script(title, contents) function is used inside the
migration task to modify some of the content on the bot while the skill is
task migrate_to: "5.1.4" do log "Starting content migration" data =  repeat i in keys(@answers) do data[i] = @answers[i] # add a new attribute data[i].enabled = true end write_script("answers", data) log "All done" end
write_scriptfunction can only be called from inside the studio, and called by a developer with enough permissions to change the bot's script.
Migration tasks can be tested in the studio by giving the task a name, and from the debug console calling
performon the task.
Skill installation migration¶
To run a migration when a skill is newly installed into a bot, specify
:install as the version:
task migrate_to: :install do log "Installing the skill..." # do your things here log "All done" end