Automatically updating Redmine from Rhodecode

For various reasons I'm switching my issue tracker from Mantis to Redmine. Redmine supports various Source Control Management systems (SCM), for Mercurial (my favourite one) they need access to a local copy of the repository, not an issue for me, but something to keep in mind.

Forward push to Redmine

After you activate the Mercurial in the general settings (/settings?tab=repositories), you need to activate the Fetch commits automatically and Enable WS for repository management
Then go to your Redmine project and open the settings\repositories page
Add a new repository and specify the details (note that you will need a local path.
Now for the Rhodecode side, we need a changegroup hook, you can add a local file on the server with the following contents (for Linux):
PROJECT="$(echo $PROJECT | tr '[A-Z]' '[a-z]')"
echo "Mercurial project: "$PROJECT
echo "Updating Changeset to Redmine Bug Tracker"
curl "http://REDMINESERVER/sys/fetch_changesets?key=$KEY&id=$PROJECT"&

Replace the REDMINESERVER with the actual webaddress of the Redmine server, and replace APIKEY with the key generated/shown by Redmine in the general settings page.

Make sure the local file is executable by the Rhodecode server user. Then switch to the Rhodecode Hooks page (/_admin/settings/hooks/edit), and add a changegroup.redmine hook and add the file location as the action:

Linking issues from commits

In the general Redmine Repositories settings page (/settings?tab=repositories) you can specify how Redmine should detect issue references from the commit message.
I have the following settings:
Be aware that Redmine expects a # in front of the issue number, so for referencing an issue you can use : ID #3. And for closing: fixes #45.

Now if you push your commit to Rhodecode, it will be forwarded to Redmine and linked to the correct issue, and show up in the tracker for that issue. If you want to track time used for the issue you can use the @ identifier followed by the amount of time use (see Redmine documentation)


Code Capture Tool Plugin Example

With the release of the Code Capture Tool v 3.2 (and up) plugins are supported in the Code Capture Tool (more details). A screencast on this process (with a demo plugin!) has been created (direct link): Unable to display content. Adobe Flash is required. Here's the Print plugin created.
Or a snippet created with the Imgur plugin:


Code Capture Tool Plugins - An introduction for developers

Plugin introduction

The Code Capture Tool 3.2 (CCT) introduces a new feature plugins. These plugins allows the user to store different info to the clipboard than the standard functions:
  • None
  • Image
  • File Path
A plugin functions as a post-capture hook, and allows you to take the stored image and alter the text of the code stored on the clipboard.


Included with the CCT 3.2 is an imgur plugin. This plugin is available if you have LabVIEW 2010 or greater, and returns a URL to a stored image on imgur.com. Imgur keeps the images online if they are viewed at least once every half year. (Thanks to Jordan Kuehn for supplying his code)


You can add your own plugins from the help window (in the plugins page), or via the context menu on the Clipboard listbox:
Plugin creation
This will open (after a confirmation dialog) a new VI from a template.


A plugin VI is created and opened. The plugin gets some parameters from the CCT when it's called:
Empty Plugin VI
  • Saved image path
    Path of the captured image file
  • FP Mode
    The capture mode of the frontpanel
  • BD Mode
    The capture mode of the block diagram
  • Snippet
    Whether this is a Snippet enabled image
  • Snippet Version
    The file version of the embedded snippet
  • Snippet Header
    Text of the snippet header
A plugin can use this information to take an action with this image. The plugin should return a Clipboard text, and a Success? status. If Success? is false the end user is informed that the plugin has failed.


To customize the text in the Clipboard listbox you should edit the Title of front panel, to give the end user more information about your plugin (in the Help dialog) the VI description is used together with the VI icon:
Plugin documentation
An end user can edit your VI directly from the Help dialog, consider locking the BD using a password if you want to prevent that.


If you want to distribute your plugins to different installation, you can choose two locations:
  • <vi.lib>\LAVA\_Code Capture Tool\Plugins
  • <LabVIEW Data>\CCT Plugins
Per default LabVIEW shares the second location between LabVIEW versions but not between users, while the first location is LabVIEW version specific, but shared between users.

If you use VIPM for creating a distributable plugin, you should use the first location (VIPM does not support LabVIEW data as a target).

Plugin inspiration

There are endless options with plugins how about this inspiration list:
  • Email image
  • Upload image to Facebook
  • Upload image to FTP
  • Add overlay to image 
  • Upload image to knowledge base
  • ......


Using Markdown to generate reports and documentation

Markdown is a hit on the internet. It's being supported by more and more platforms, it started for me with Stackoverflow and later on my favourite project hosting website (Bitbucket) made it their default Wiki markup language.

And I like Markdown, it's syntax is quite simple, you can read the document and get a feel for it's structure (emphasize, headings, lists) without a conversion to HTML. But it had a thing missing, a LabVIEW Markdown generator.
And it bugged me.
So I created a project (a while ago) in LabVIEW, and just the last week I took the time to finish the project.
It's now a Class that overrides the LabVIEW Report Generation VIs, you can use your existing 'write to HTML/DOC/XLS' code to write a Markdown report.

It's not a full override of the Report Generation toolkit VIs, some functionality is not available in Markdown (margins) or in the toolkit's generic VIs (headings).

You can download the package from Bitbucket, and file your feature requests or bugs there as well.

Now what to do with this tool?
Well I wrote a simple VI that took some pre-written Markdown, added information about the toolkit, and pushed the information into the Bitbucket wiki. So the documentation of the toolkit is using the toolkit.
A screenshot of this VI is this:
As you can see, the only special from a normal report is that we instantiate a Markdown class that we upcast to a generic Report class. And the we use normal report functions (add text, add image) to generate valid Markdown.
Sometimes it takes some tweaking to get the result you want, adding extra linefeeds after/before an image is sometimes necessary (and can vary depending on your MD to HTML converter).

Please spread the word about Markdown, and the report toolkit, post your findings here. Add feature requests and bugs to the Bitbucket repo.

PS Markdown even got a semi-official logo [M↓]

PPS The report generation VIs are a mess. Please NI start over from scratch.