Writing A Plugin

UCD (UrbanCode Deploy) is designed in such a way that any software that you currently use in your development lifecycle can be supported by writing a plugin. Writing a plugin for UCD is pretty straight forward but it can seem like there is a lot of magic and hand-waving happening. Once you understand the requirements and learn the nuances writing a plugin for UDC is pretty simple. Here is what you need to get started: working knowledge of JavaScript & Groovy, and three xml files (plugin, update, & info). Plugin.xml and update.xml are required files while info.xml is optional, it is used to describe the plugin and to provide release notes.

Example of Plugin.xml

<?xml version="1.0" encoding="UTF-8"?>
<plugin xmlns="http://www.UrbanCode.com/PluginXMLSchema_v1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<header>
<identifier id="plugin_id" version="version_number" name="Plug-in Name" />
<description>Description goes here </description>
<tag>Plugin_type/Plugin_subtype/Plugin_name</tag>
</header>
<step-type name="Step_Name">
<description />
<properties>
<property name="property_name" required="true">
<property-ui type="" label="label" description="description goes here"
default-value="" />
</property>
</properties>
<post-processing>
<![CDATA[
if (properties.get("exitCode") != 0) {
properties.put("Status", "Failure");
}else {
properties.put("Status", "Success");
}
]]>
</post-processing>
<command program="${path_to_tool">
<arg value="parameters_passed_to_tool" />
<arg path="${p:jdbcJar}" />
<arg file="command_to_run" />
<arg file="${PLUGIN_INPUT_PROPS}" />
<arg file="${PLUGIN_OUTPUT_PROPS}" />
</command>
</step-type>
</plugin>

The <header> information is very basic and contains three additional elements.
<identifier> is information that is used to id the plugin you are writing within UCD as well on the UCD’s website if you submit the plugin.
<description> describes the plugin. The description information will be displayed under the settings section after loading the plugin into UCD.
<tag> is used to categorize the plugin against the other the plugins that are already installed.

The <step-type> is also pretty straight forward. <step-type> is a single action being taken. If you are creating a plugin that needs to create a file, write to the file, and move the file to a new location, you would have three <step-type> tags:

<step-type name=”Create File”>
<step-type name=”Write to File”>
<step-type name=”Move File”>

The <command> element is run before the <post-processing> element.  The individual steps are run by invoking a scripting tool that is defined within the command element. This is where the scripting language becomes important. You can use any scripting language you choose including JavaScript, Ruby, or Pearl but Groovy is supported natively.

Basically you are creating a JavaScript or Groovy file that will interacts with either an API or your program directly. The steps you are creating in the plugin.xml file are an intermediary between UCD and your program. In these steps you are telling UCD how to interact with your program.

The <post-processing> element is run after the <command> element and sets the output properties, provides error handling, and determines if the interaction between your plugin and UCD has completed successfully. This section must be written in JavaScript.

Example of Upgrade.xml

<?xml version="1.0" encoding="UTF-8"?>
<plugin-upgrade xmlns="http://www.&company;.com/UpgradeXMLSchema_v1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
</plugin-upgrade>

The upgrade.xml file is required but doesn’t have to be filled out. If this is your first version, then there wouldn’t be any upgrades. You can update this section with your information and leave it blank until there is a need to update your plugin.

Example of Info.xml

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<pluginInfo>
<!-- **author name IS required** -->
<author name="IBM">
<organization></organization>
<bio />
</author>
<!-- **intergration type IS Required** -->
<integration type="Automation" />
<!-- **source is NOT required** -->
<!-- <source url=""/> -->
<!-- **license type is NOT required** -->
<!-- <licenses> <license type=""/> </licenses> -->
<!-- **tool-description IS required** -->
<tool-description></tool-description>
<!-- **related-info is NOT required** -->
<!-- <related-info> <link title="" type="" description="" url =""/> </related-info> -->
<!-- **meta-html in NOT required** -->
<meta-html>
<meta content="" name="description" />
<meta content="" name="keywords" />
</meta-html>
<!-- Do not change the release-version, the build process injects it. -->
<release-version>0.0</release-version>
<release-notes>
<!-- **release-note IS required** -->
<release-note plugin-version="0.0">
</release-note>
</release-notes>
</pluginInfo>

Advertisements
Tagged with: , , , , , , , ,
Posted in Uncategorized

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

DevOps

Avnet Services DevOps Team Blog

BamBytes

Just another WordPress site

Crossing Silos

DevOps only works if you cross boundaries

Avnet Services DevOps

Avnet Services DevOps Team Blog

%d bloggers like this: