Hi Jesper, It seems that you need to add more information to jobs pages and make the interaction with Jenkins more user-friendly and foolproof. To make it happen I would suggest to add a layer of abstraction on top of Jenkins.
Using simple interface and communicating with Jenkins through REST interface you will accomplish the following: - description of jobs and parameters in any way you find suitable - exposed just the right amount of information and/or configuration parameters - any types of validations on input parameters - make it in the form of wizard, where the first page will have job/parameters description and the next page will ask for values and perform validation - any types of notifications - better access control - any specific area can have it's own page/tab and it is not necessarily the same hierarchy as on Jenkins build server - Jenkins can change the home, yet your web interface will be intact Yes, it will involve some coding on your side, but it will be simple and beautiful solution :-) Just my 2 cents. Thank you, Andrey On Fri, Jun 15, 2012 at 3:24 AM, Jesper Terkelsen < jesper.terkel...@gmail.com> wrote: > Hi all > > I am using Jenkins as a system that monitors cron jobs, and allows users > to start various shell scripts on servers with parameters. > > Jenkins serves this purpose really well, because you can: > > - Use the company LDAB server for login > - Control who has access to what > - Monitor the success of the job. > - Log the output of the scripts, for debugging. > - And it is fairly easy for non technical people to start jobs via a > web GUI, allowing the development and operations teams to outsource some > trivial tasks to other departments. > > I have the following problems with the last point though. > > 1. If i send the user to the job page, where i can put a description > on what the job does. > - Pro: The users can read the documentation on how to do the job, > which will make them more likely to put in the correct parameters, and > not > run the job if it is not the correct one. > - Con: The users cannot always easy find the build button to the > left, and it will require them an ekstra click to start the job. > 2. If i send the user directly to the build now > (/build?delay=0sec). The page will include the following: Job name, the > text "This build requires parameters:" the parameters, and a build > button. > - Pro: It is far more easy for the users to understand what to do, you > put in arguments, and hit the build button. > - Con: The user might to a mistake, because he does not read my > documentation on the job. Causing wrong parameters, or the job being > started when it was not necessary or wrong. > > Remember this applies to the non technical users, developers or system > administrators do not have this problem. > > My suggestions for a solution could be one of the following. > > - Add the project description on the top of the build now page. > - Allow the job creator to put in another description for the build > now page. > - Add a parameters that is not a real argument, but just put in a > description. > > Also allowing the job creator to rename the "build" button, to something > else that makes more sense in relation to what the job does, would be > useful. > > My questions are > > - Does anyone else have this problem ? > - If yes, what was your solution, did you find any plugins that i have > not found to help you. > - Is it possible to develop a plugin that does that ? (this would > requere that you can extend the build now page, or cheat with a text only > parameter) > > I have tried to search for plugins, and even looked into the plugin api a > bit to see if the build page is extendable, but it does not look like it is > possible. (i am not sure about the last one though) > > What do you think? > > Best regards > Jesper Terkelsen > > > >
