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 <[email protected]> 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 <
> [email protected]> 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
>>
>>
>>
>>
>

Reply via email to