Thank you daniel this was really useful for me. I think this is enough for me to be able to send the user directly to the build now, and still get the user to read the documentation before starting the job.
Best regards Jesper On Saturday, June 16, 2012 3:32:45 PM UTC+2, Daniel Beck wrote: > > 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 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 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 > > > > > > > > > > > >
