Plugin Toolbar

The plugin editor toolbar provides access to advanced configuration features. These tools shape how your plugin interacts with other plugins, machines, and VLANs during builds.

Dependencies

Dependencies declare that your plugin relies on another plugin’s output. Open the Dependencies panel to manage them.

How Dependencies Work

When your YAML references another plugin’s output, you wrap the plugin name in curly braces:

- name: Join the domain
  win_domain_membership:
    dns_domain_name: "{ActiveDirectoryDomainController}"

The {<PluginName>} syntax tells the build system that this plugin depends on ActiveDirectoryDomainController. At build time, the referenced plugin runs first, and its output is available to your plugin.

In the Monaco editor, dependency references are highlighted in purple so they’re easy to spot.

Managing Dependencies

The Dependencies panel shows:

• Plugins I depend on — plugins your YAML references via {<PluginName>}
• Plugins that depend on me — other plugins that reference your plugin

If your YAML contains dependency references that aren’t mapped, the editor shows an unmapped dependencies warning. Use the Dependencies panel to resolve these by linking them to the correct plugin.

Parent Server Plugins

Parent Server Plugins define cross-machine dependencies — where a plugin on one machine depends on a plugin running on a different machine.

Example: Domain Join

A “Domain Join” plugin on a workstation needs the “Active Directory Domain Controller” plugin to be running on a separate server machine. The parent server plugin link tells the build system about this relationship.

Setting Up Parent Server Links

1. Open the Parent Server Plugins panel
2. Add the parent plugin (e.g., ActiveDirectoryDomainController)
3. Optionally set match parameters:
   • Child Match Param — a parameter on your plugin (e.g., DomainName)
   • Parent Match Param — a parameter on the parent plugin (e.g., DomainNameFQDN)

When match parameters are configured, the system can automatically detect cross-machine dependencies during builds. If the child’s DomainName matches the parent’s DomainNameFQDN, the system recommends linking them.

Pre-Check Warnings

Parent server links are used during build pre-checks. If your scenario includes a plugin that expects a parent server plugin but no matching plugin exists on another machine, you’ll see a warning before the build starts.

Automated Actions

Automated Actions let your plugin automatically update VLAN or machine settings when certain events occur. Open the Automated Actions panel to configure them.

Triggers

Trigger	When It Runs
On Apply	When the plugin is first added to a machine
On Upgrade	When the plugin is upgraded to a new version
On Param Change	When a referenced parameter value changes

Target Entities

Actions can update fields on either the VLAN or the Machine where the plugin is applied.

VLAN fields:

Field	Description
Nickname	VLAN display name
DNS Forwarding Targets	DNS forwarding entries
Static Host Mappings	Static DNS records
Gateway	Gateway address
Address	VLAN address
Provide DHCP	Enable/disable DHCP
DHCP Range Start/End	DHCP range boundaries

Machine fields:

Field	Description
Nickname	Machine display name
RAM (GB)	Memory allocation
CPU Cores	Processor allocation
User Controllable	Whether students can interact with this VM
VM Dock	Whether to show in the student VM dock
Username/Password	Default credentials

Value Mapping

Actions map parameter values to target fields. For example, a DNS Server plugin might automatically add a DNS forwarding entry to the VLAN when applied:

• Target Entity: VLAN
• Target Field: DNS Forwarding Targets
• Operation: Add or Update
• Value Mapping: { "domainName": "${DomainNameFQDN}", "dnsForwardingTargetIP": "${TargetIP}" }

Values prefixed with ${} reference plugin parameters. Static values (without ${}) are also supported.

Automation Preview

When a trigger fires (e.g., you add a plugin to a machine), the system shows an Automation Preview dialog listing all recommended changes. You can accept or reject individual recommendations before they’re applied.

Compatible Templates

Open the Templates panel to set which VM templates your plugin is compatible with. Only machines running a compatible template will allow your plugin to be added.

Templates are grouped by operating system (Windows Server 2022, Ubuntu, Kali, etc.).

Resources (Vault Files)

The Resources panel manages files that your plugin needs during execution — configuration files, scripts, certificates, and other artifacts.

Uploading Files

1. Open the Resources panel
2. Click Upload to add files
3. Files are stored in the plugin’s vault and available during builds

Referencing Files in YAML

When your YAML uses the copy or template module, the src path references files from your plugin’s resource vault:

- name: Copy configuration file
  copy:
    src: "config/apache.conf"
    dest: "/etc/apache2/apache2.conf"

The Resources panel shows the full file tree of uploaded resources so you can verify paths match your YAML.

Note

Uploading vault files requires the Launch Builds permission. Users with Edit (No Build) access can modify YAML and parameters but cannot upload resources.

Rogue Oracle (AI Assistant)

The Rogue Oracle button opens an AI assistant sidebar that can help you write and edit plugin YAML. Oracle understands the Rogue Arena plugin format and can generate Ansible tasks, suggest parameter configurations, and debug YAML issues.

Oracle appears as a side panel alongside the Monaco editor, so you can chat with it while viewing and editing your code.