If it's just the job description on the build page, you could add the following JS snippet to any of your job's parameter descriptions:
<script> if(document.URL == "http://jenkins/job/jobname/build?delay=0sec";) { new Ajax.Request('http://jenkins/job/jobname/api/json', { onSuccess: function(transport) { var data = transport.responseText.evalJSON(); var target = $$("p").first(); if (target != null) target.update(data.description); } }); }</script> This will change the "This build requires parameters" text to the job description when viewing the Build Now page. On pages like a past build's parameters, it'll run and immediately quit. It seems to work with authentication as well. I have not used this productively. One possible issue is the accumulation of JS in your builds' parameter data. Regards, Daniel On 16.06.2012, at 13:04, Jesper Terkelsen 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 > > > > >
