Hi Jesper, I guess it is easier when you see the problem at hand, and know better which parts can be reused and what should be changed.
Good thing is that you have so many ways to get it solved :-) Regards, Andrey On Jun 16, 2012, at 4:04 AM, Jesper Terkelsen <jesper.terkel...@gmail.com> wrote: > Hi Andrey > > Thank you for the feedback. I think this is also the way to go for me. > > But i will have to re-implement some of the features i already have now, most > specifically the login part. > And i have to find a way to preserve the user credentials when doing the REST > call. > > Also i use some really nice plugins for generating drop downs for parameters, > for some of the scripts. Those i will have to implement myself also. > > Perhaps it is easier to patch jenkins itself instead. > > I will try different approaches, but i would prefer not to create a complete > new system because of this :-) > > I might also just live with the current solution, and try to educate my users > better. > > Best regards > Jesper > > On 16 June 2012 00:05, Andrey Myatlyuk <myatl...@gmail.com> wrote: > 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. > 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. > 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 > > > > >
