This box searches only this space. The box at the upper right searches the entire iPlant wiki.

Skip to end of metadata
Go to start of metadata

After you submit your dockerfile, you will receive an email like this:

From: noreply@iplantcollaborative.org
Subject: Tool Request HiSat2 Status Changed to Completion
Date: October 5, 2015 at 11:17:57 AM MST
To: XXXX@iplantcollaborative.org

Your tool, HiSat2, is now available in the Discovery Environment. Please see the comments below:

Hey Eric. Your tool request for hisat 2 has been completed. Before you can use your tool in the Discovery Environment, a user interface must be defined. The tool is currently on our staging system where you will login into http://dapple.iplantcollaborative.org . Here you will create an interface and test out the tool to see if it works. If it does, we will upload it to production for public use. Let me know when you want to move it to production. I will have to port over the UI you created.

You will find your tool listed in the Tool Editor(Tito) under the name hisat2-2.0.0. For information on how to create a definition and documentation for your tool, please see the Tito documentation pages located at https://pods.iplantcollaborative.org/wiki/display/DEmanual/Creating+a+New+App+Interface

  • No labels

3 Comments

  1. This tutorial is great. But it would be better if the example application took some user inputs. For example, some numerical parameters and a file input. In such a case, we can learn some more detailed information of how the user's input is passed on to each docker run, and how it is connected to the application interface on the Discovery Environment on iPlant.

    1. Thanks Bo. We'll try to get such an example added soon.

  2. Hey Eric, this email looks like an older version than what'd be sent out now. It'd be good to get it reflecting the current emails, since some of what it's saying seems out of date.

    Most notably, perhaps, we'd prefer that dapple only be used for verifying the tool basically works, and most app UI work be done later on, in production after the tool has been copied over (in a private workspace, of course). The task of copying over app UIs is not very good, and once the tool has been added to the production DE it's still possible to hide the in-development app by way of a private workspace, so this is preferred.