Hi John, On Jun 7, 2012, at 11:55 PM, John Chilton wrote:
> I have read through the documentation a couple times, but I still have > a few questions about the recent tool shed enhancements. > > At MSI we have a testing environment and a production environment and > I want to make sure the tool versions and configurations don't get out > of sync, I would also like to test everything in our testing > environment before it reaches production. > > Is there a recommended way to accomplish this rather than just > manually repeating the same set of UI interactions twice? > > Can I just import tools through the testing UI and run the > ./scripts/migrate_tools/XXXX scripts on our testing repository and > then move the resulting migrated_tools_conf.xml and > integrated_tool_panel.xml files into production? I have follow up > questions, but I will wait for a response on this point. Tools that used to be in the Galaxy distribution but have been moved to the main Galaxy tool shed are automatically installed when you start up your Galaxy server and presented with the option of running the migration script to automatically install the tools that were migrated in the specific Galaxy distribution release. If you choose to install the tools, they are installed only in that specific Galaxy instance. Installation produces mercurial repositories that include the tools on disk in your Galaxy server environment. Several other things are produced as well, including database records for the installation. Each Galaxy instance consists of it's own separate set of components, this installation process must be done for each instance. The installation is fully automatic, requiring little interaction on the part of the Galaxy admin, and doesn't require much time, so performing the process for each Galaxy instance should not be too intensive. Also, the tools that are! installed into each Galaxy instance's tool panel are only those tools that were originally defined in the tool panel configuration file (tool_conf.xml). This approach provides for the case where each Galaxy instance having different tools defined will not be altered by the migration process. > > Also as you are removing tools from Galaxy and placing them into our > tool shed, what is the recommended course of actions for deployers > that have made local minor tweaks to those tool configs and scripts > and adapt them to our local environments? Along the same lines, what > is the recommended course of action if we need to make minor tweaks to > tools pulled into through the UI to adapt them to our institution. In both cases you should upload your proprietary tools to either a local Galaxy tool shed that you administer, or the main Galaxy tool shed if you want. You can choose to not execute any of the tool migration scripts, so the Galaxy tools that were migrated from the distribution will not be installed into your Galaxy environment. You can use the Galaxy admin UI to install your proprietary versions of the migrated tools from the tool shed in which you chose to upload and store them. New versions of the tools can be uploaded to respective tool shed repositories over time. > > Thanks for your time, > -John > > ------------------------------------------------ > John Chilton > Senior Software Developer > University of Minnesota Supercomputing Institute > Office: 612-625-0917 > Cell: 612-226-9223 > ___________________________________________________________ > Please keep all replies on the list by using "reply all" > in your mail client. To manage your subscriptions to this > and other Galaxy lists, please use the interface at: > > http://lists.bx.psu.edu/ ___________________________________________________________ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
