figshare is a platform where users can upload and share images, graphs, presentations and other documents. These artifacts can be generated using different tools - including Jenkins. The BioUno figshare Plug-in integrates Jenkins and figshare. The figshare API uses OAuth 1.0, and requires data such as client key, client secret, token key and token secret stored in Jenkins.
What the Jenkins Credentials Plug-in does, basically, is store these credentials in a way that it is both safer and easier to maintain in Jenkins. Before that, users would add passwords as parameters in jobs or store credentials globally in Jenkins via plug-ins. This resulted in security problems, and was also difficult to maintain with a high number of jobs with different credentials.
More than a year ago I approached Bruno via a series of posts on the BioUno developer’s forum and discussed my frustration with the available Jenkins user interface controls for generating advanced, dynamic user interfaces for scientific applications. I had seen partial implementations of what I thought we needed in some Jenkins plugins, but none of them was well maintained or provided in a single plugin the features I wanted. So, I asked Bruno whether it would be possible to create a new plugin with all of these features? He said ‘yes’ and he took on this challenge. One of Bruno’s first questions was ‘What should we call this new plugin?’. To credit the BioUno project contribution and my expectation that this UI plugin would make all the related incomplete plugins obsolete, I answered ‘Uno-Choice’, the one choice for all your needs!
In this blog entry, I will describe a bit of the Uno-Choice plugin history until its contribution to the Jenkins project with a new name, Active Choices Plugin.
This is the first part of a series of posts about a Java API for PBS servers, compliant with the DRMAA spec.
This post could also be entitled “Why we won’t use DRMAA for our Jenkins plug-in”, with spoilers included. After working on a prototype DRMAA PBS Java library for a few days, I finally understand why we can’t use DRMAA v1 for the plug-in.
When you use Jenkins for analytics it is important to deliver consistent analysis reports from each build. There are a few different ways that you can create graphical, tabular and/or textual analysis reports, but one thing that becomes clear immediately is that you also require a certain level of dynamic behavior. Dynamic behavior is required so that you can easily adapt the reports to the underlying data whose format and content will likely change even when the same type of analysis is performed.
In this this blog entry, I will describe how I have used the Summary Display and Scriptler plugins to create a simple but effective framework for displaying consistent but dynamic reports following numerical data analysis using the R plugin.
This is the first part of a series of posts about a Java API for PBS servers, compliant with the DRMAA spec. PBS is a type of batch server, or distributed resource manager (DRM). It manages resources like CPU and memory in a network of computers, and is able to schedule jobs to run utilizing the maximum of these resources.
We have a PBS Plug-in for Jenkins, that enables us to submit and monitor jobs from Jenkins to a PBS server. James Hetherington proposed enhancements for the pbs-java-api and PBS Plug-in, including supporting other batch servers like SGE.