Jenkins › Jenkins users

Userbility on when starting build with parameters

Classic

List

Threaded

11 messages Options

Jesper Terkelsen

Userbility on when starting build with parameters

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

ganncamp

Re: Userbility on when starting build with parameters

Don't forget that you can add a description to each parameter (i.e. field-by-field documentation) and default values...

:-)

Ann

**********************************************************

Privileged and/or confidential information may be contained in this message. If you are not the addressee indicated in this message (or are not responsible for delivery of this message to that person) , you may not copy or deliver this message to anyone. In such case, you should destroy this message and notify the sender by reply e-mail.

If you or your employer do not consent to Internet e-mail for messages of this kind, please advise the sender.

Shaw Industries does not provide or endorse any opinions, conclusions or other information in this message that do not relate to the official business of the company or its subsidiaries.

**********************************************************

Andrey Myatlyuk

Re: Userbility on when starting build with parameters

In reply to this post by Jesper Terkelsen

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

Jesper Terkelsen

Re: Userbility on when starting build with parameters

In reply to this post by ganncamp

Yeah i know, but it does not really help me with an overall description on what to, and weather or not the user should run the job at all.

On 15 June 2012 17:50, Ann Campbell <[hidden email]> wrote:

Don't forget that you can add a description to each parameter (i.e. field-by-field documentation) and default values...

:-)
Ann

**********************************************************
Privileged and/or confidential information may be contained in this message. If you are not the addressee indicated in this message (or are not responsible for delivery of this message to that person) , you may not copy or deliver this message to anyone. In such case, you should destroy this message and notify the sender by reply e-mail.

If you or your employer do not consent to Internet e-mail for messages of this kind, please advise the sender.
Shaw Industries does not provide or endorse any opinions, conclusions or other information in this message that do not relate to the official business of the company or its subsidiaries.

**********************************************************

Jesper Terkelsen

Re: Userbility on when starting build with parameters

In reply to this post by Andrey Myatlyuk

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

Daniel Beck

Re: Userbility on when starting build with parameters

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

Kamal Ahmed

Jenkins plugin to create dashboards

Hi,

Is there a plugin, which i can use to create dashboards that can display reports from various plugins on one page.

Thanks,

-Kamal.

Ulli Hafner

Re: Jenkins plugin to create dashboards

On 06/16/2012 09:13 PM, Kamal Ahmed wrote:

Hi,
Is there a plugin, which i can use to create dashboards that can display reports from various plugins on one page.

Thanks,

-Kamal.

There is the dashboard view plug-in: https://wiki.jenkins-ci.org/display/JENKINS/Dashboard+View

Ulli

Kamal Ahmed

Re: Jenkins plugin to create dashboards

Thanks Ulli,

i just started using it.

Here is what i am trying to do. Its a bit advanced, but if i get this to work, then i can really add relevant content to one screen on Jenkins.

1. Use Jenkins Python API https://wiki.jenkins-ci.org/display/JENKINS/Remote+access+API

2. The API is accessable via http://192.168.1.104:8080/api/?

3. so when i use http://192.168.1.104:8080/job/PYGMENTS/api/json

i get the following in JSON format:

{"actions":[{},{},{},{},{},{},{},{},{}],"description":"","displayName":"PYGMENTS","displayNameOrNull":null,"name":"PYGMENTS","url":"http://192.168.1.104:8080/job/PYGMENTS/","buildable":true,"builds":[{"number":21,"url":"http://192.168.1.104:8080/job/PYGMENTS/21/"},{"number":16,"url":"http://192.168.1.104:8080/job/PYGMENTS/16/"},{"number":15,"url":"http://192.168.1.104:8080/job/PYGMENTS/15/"},{"number":14,"url":"http://192.168.1.104:8080/job/PYGMENTS/14/"},{"number":13,"url":"http://192.168.1.104:8080/job/PYGMENTS/13/"},{"number":12,"url":"http://192.168.1.104:8080/job/PYGMENTS/12/"},{"number":11,"url":"http://192.168.1.104:8080/job/PYGMENTS/11/"},{"number":10,"url":"http://192.168.1.104:8080/job/PYGMENTS/10/"},{"number":9,"url":"http://192.168.1.104:8080/job/PYGMENTS/9/"},{"number":8,"url":"http://192.168.1.104:8080/job/PYGMENTS/8/"}],"color":"yellow","firstBuild":{"number":8,"url":"http://192.168.1.104:8080/job/PYGMENTS/8/"},"healthReport":[{"descri
ption":"No xml report files found for cpd","iconUrl":"health-00to19.png","score":0},{"description":"Cobertura Coverage: 60% (8885/14925) Lines","iconUrl":"health-60to79.png","score":75},{"description":"Build stability: 1 out of the last 5 builds failed.","iconUrl":"health-60to79.png","score":80},{"description":"Test Result: 0 tests failing out of a total of 768
 tests.","iconUrl":"health-80plus.png","score":100}],"inQueue":false,"keepDependencies":false,"lastBuild":{"number":21,"url":"http://192.168.1.104:8080/job/PYGMENTS/21/"},"lastCompletedBuild":{"number":21,"url":"http://192.168.1.104:8080/job/PYGMENTS/21/"},"lastFailedBuild":{"number":16,"url":"http://192.168.1.104:8080/job/PYGMENTS/16/"},"lastStableBuild":{"number":13,"url":"http://192.168.1.104:8080/job/PYGMENTS/13/"},"lastSuccessfulBuild":{"number":21,"url":"http://192.168.1.104:8080/job/PYGMENTS/21/"},"lastUnstableBuild":{"number":21,"url":"http://192.168.1.104:8080/job/PYGMENTS/21/"},"lastUnsuccessfulBuild":{"number":21,"url":"http://192.168.1.104:8080/job/PYGMENTS/21/"},"nextBuildNumber":22,"property":[{}],"queueItem":null,"concurrentBuild":false,"downstreamProjects":[],"scm":{},"upstreamProjects":[]}

Now, if we see as an example:

https://wiki.jenkins-ci.org/display/JENKINS/Add+a+Google-O-Meter+to+a+view

if we add the following Javascript in the description:

<script>
var xmlhttp = null;
if (window.XMLHttpRequest)
    xmlhttp = new XMLHttpRequest();
else if (window.ActiveXObject) {
    if (new ActiveXObject("Microsoft.XMLHTTP"))
        xmlhttp = new ActiveXObject("Microsoft.XMLHTTP");
    else
        xmlhttp = new ActiveXObject("Msxml2.XMLHTTP");
}
var url = document.location + "/api/xml?xpath=count%28//job[color=%22blue%22]%29div+count%28//job%29"
xmlhttp.open("GET", url, false);//false means synchronous
xmlhttp.send()
var buildSuccessFraction= xmlhttp.responseText
document.write('<img src="http://chart.apis.google.com/chart?chs=320x160&cht=gom&chd=t:' + buildSuccessFraction * 100.0 + '&chxt=x,y&chxl=y|0:||1:|failure|success">')
</script>

I understand this is wrong example since this is XML, but i could not find a JSON Example.
But you get the picture in this way we can create many dashboards, like annotated timeline:

https://developers.google.com/chart/interactive/docs/gallery/annotatedtimeline#Example

applied to Jenkins
 builds.

Thanks,
-Kamal.

From: Ulli Hafner <[hidden email]>
To: [hidden email]
Sent: Sunday, June 17, 2012 12:13 PM
Subject: Re: Jenkins plugin to create dashboards

On 06/16/2012 09:13 PM, Kamal Ahmed wrote:

Hi,
Is there a plugin, which i can use to create dashboards that can display reports from various plugins on one page.

Thanks,

-Kamal.

There is the dashboard view plug-in: https://wiki.jenkins-ci.org/display/JENKINS/Dashboard+View

Ulli

Andrey Myatlyuk

Re: Userbility on when starting build with parameters

In reply to this post by Jesper Terkelsen

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

Jesper Terkelsen

Re: Userbility on when starting build with parameters

In reply to this post by Daniel Beck

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
>
>
>
>
>