Re: Suggestions for a jenkins dashboard

2017-11-26 Thread niristotle okram
Thanks for the suggestion, i will definitely give a try on that!

On Sun, Nov 26, 2017 at 7:17 AM Baptiste Mathus  wrote:

> Being the maintainer of Radiator View Plugin, I'm not very objective, but
> I can at least confirm it seems like it would work very fine for your goal.
> We do have it deployed and used on our instance, and it works well for us.
> And it was also used by many teams, and probably still is, in my previous
> company.
>
> My 2 cents
>
> 2017-11-08 18:00 GMT+01:00 James Telfer :
>
>> We use Atlasboard (https://bitbucket.org/atlassian/atlasboard) along
>> with the Atlasboard Jenkins Package (
>> https://github.com/incentro/atlasboard-jenkins-package) to display build
>> status.
>>
>> Pretty simple to get set up as it goes, and the views are driven by
>> creating views in Jenkins, so very easy to customise what gets shown where
>> one it's set up.
>>
>> On Monday, 6 November 2017 16:43:43 UTC, ok999 wrote:
>>>
>>> hi all,
>>>
>>> i am looking for suggestion on some simple (yet proven) jenkins
>>> dashboards. I don't want to spend time on somethings that's already there.
>>>
>>> I am just trying to cast some job status, nothing fancy. But being if
>>> fancy is a feature, i will take it :)
>>>
>>> Thanks !
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Jenkins Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jenkinsci-users+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-users/4f36d0c0-2c65-4b70-9dab-d55b3c8268e2%40googlegroups.com
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-users/CANWgJS6sJ%3DhGxWz%3DGHbk3Urc%3D5r2sXQhFbzqNuRNkA4VR6irTw%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Sent from mobile device, excuse typos if any.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/CAPzcO4g6JJ9qHaL-jbT1QVriFH2Fx1wbp2piW-7sXrpsc%2BkWZg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Suggestions for a jenkins dashboard

2017-11-26 Thread Baptiste Mathus
Being the maintainer of Radiator View Plugin, I'm not very objective, but I
can at least confirm it seems like it would work very fine for your goal.
We do have it deployed and used on our instance, and it works well for us.
And it was also used by many teams, and probably still is, in my previous
company.

My 2 cents

2017-11-08 18:00 GMT+01:00 James Telfer :

> We use Atlasboard (https://bitbucket.org/atlassian/atlasboard) along with
> the Atlasboard Jenkins Package (https://github.com/incentro/
> atlasboard-jenkins-package) to display build status.
>
> Pretty simple to get set up as it goes, and the views are driven by
> creating views in Jenkins, so very easy to customise what gets shown where
> one it's set up.
>
> On Monday, 6 November 2017 16:43:43 UTC, ok999 wrote:
>>
>> hi all,
>>
>> i am looking for suggestion on some simple (yet proven) jenkins
>> dashboards. I don't want to spend time on somethings that's already there.
>>
>> I am just trying to cast some job status, nothing fancy. But being if
>> fancy is a feature, i will take it :)
>>
>> Thanks !
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/jenkinsci-users/4f36d0c0-2c65-4b70-9dab-d55b3c8268e2%40googlegroups.
> com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/CANWgJS6sJ%3DhGxWz%3DGHbk3Urc%3D5r2sXQhFbzqNuRNkA4VR6irTw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Suggestions for a jenkins dashboard

2017-11-08 Thread James Telfer
We use Atlasboard (https://bitbucket.org/atlassian/atlasboard) along with 
the Atlasboard Jenkins Package 
(https://github.com/incentro/atlasboard-jenkins-package) to display build 
status.

Pretty simple to get set up as it goes, and the views are driven by 
creating views in Jenkins, so very easy to customise what gets shown where 
one it's set up.

On Monday, 6 November 2017 16:43:43 UTC, ok999 wrote:
>
> hi all, 
>
> i am looking for suggestion on some simple (yet proven) jenkins 
> dashboards. I don't want to spend time on somethings that's already there. 
>
> I am just trying to cast some job status, nothing fancy. But being if 
> fancy is a feature, i will take it :) 
>
> Thanks ! 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/4f36d0c0-2c65-4b70-9dab-d55b3c8268e2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Suggestions for a jenkins dashboard

2017-11-08 Thread Michael Pailloncy
You could be interested in Radiator View Plugin
 or Build
Monitor plugin
. They
display boxes with jobs status in green/yellow/red.
There is also a more custom dashboard detailed here :
https://jenkins.io/blog/2016/01/10/beautiful-jenkins-dashboard/ (not
personally tested)

Hopefully it helps.

Le 6 nov. 2017 17:43, "niristotle okram"  a écrit :

> hi all,
>
> i am looking for suggestion on some simple (yet proven) jenkins
> dashboards. I don't want to spend time on somethings that's already there.
>
> I am just trying to cast some job status, nothing fancy. But being if
> fancy is a feature, i will take it :)
>
> Thanks !
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/ms
> gid/jenkinsci-users/CAPzcO4j56LFyNE2dETPWHqmWDx7rd%
> 2BeqcdBOC9WOzYS_qKu9XA%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/CAPO77c3hjhL0-ZuEdBC4C-XrTHMK41_h7bTpUHVW%3Dq-VcAKGvQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Suggestions needed

2016-10-27 Thread Logan MAUZAIZE
I don't think blocking slave/agent for long duration is a good idea, except 
if a single test can be run at once for a particular platform. Thus, you 
must consider the hosting platform as a jenkins slave/agent and use a 
waiter script.

If you need feed back managed by Jenkins, may be you can use an additional 
job triggered using a project authentification token.

Le jeudi 27 octobre 2016 15:59:12 UTC+2, Jeffrey Harris a écrit :
>
> I think our longest test is 20 hours. Also, any number of tests can be 
> spooled at a particular time.
>
> The legacy system just puts the job in the queue and returns. 
>
> Jeff
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/74ce16cf-0797-4ffb-ad93-4a6ef37b4823%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


RE: Suggestions needed

2016-10-27 Thread Jeffrey Harris
I think our longest test is 20 hours. Also, any number of tests can be spooled 
at a particular time.

The legacy system just puts the job in the queue and returns. 

Jeff

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/719b01a0-52bd-499c-a962-9319fbdaee1c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


RE: Suggestions needed

2016-10-27 Thread Teichner Peter
Just to add to that - make sure you set the timeout on the shell / ssh to 
unlimited otherwise it will time out

-Original Message-
From: jenkinsci-users@googlegroups.com 
[mailto:jenkinsci-users@googlegroups.com] On Behalf Of John Mellor
Sent: 27 October 2016 13:34
To: jenkinsci-users@googlegroups.com
Subject: RE: Suggestions needed

How long does the hardware testing take?  If its only a couple of hours, why 
not just run a shell step to ssh or whatever out to the hardware and test?  A 
shell step normally blocks until completed, so the job will be in-progress 
until the tests are done.

-Original Message-
From: jenkinsci-users@googlegroups.com 
[mailto:jenkinsci-users@googlegroups.com] On Behalf Of Jeffrey Harris
Sent: October-26-16 23:03
To: Jenkins Users
Subject: Suggestions needed

I'm trying to figure out a way to automate submitting a test to our hardware 
testbed and waiting for the test to complete so that the Jenkins job can report 
its status. 

Are either of the ideas below possible?

Create a Jenkins job that submits the test (this is the easy part), waits until 
the job is informed the test is complete and then processes the results. 

The other idea I've had is to create a spool_test job that only spoils the 
test. When the test is complete it starts a complete_test job to process the 
results. 

Ultimately I'd like to have a regress_tests job that spools several tests. But 
I'm not sure with the second approach how to tell regress_tests that it's not 
done until all the complete_test jobs (that it doesn't directly start) are 
done. 

Thanks for any help,
Jeff

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/c7619784-6c20-471f-b727-de7bc57495ca%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/5aaafbbef9dd47cca4abc2d90886539f%40mbx02cmb01p.esentire.local.
For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/1D7A50BF5AC1D449A7E018A3CE1D8B339DD2B94E%40CHX-EXMBX-06.hq.k.grp.
For more options, visit https://groups.google.com/d/optout.


RE: Suggestions needed

2016-10-27 Thread John Mellor
How long does the hardware testing take?  If its only a couple of hours, why 
not just run a shell step to ssh or whatever out to the hardware and test?  A 
shell step normally blocks until completed, so the job will be in-progress 
until the tests are done.

-Original Message-
From: jenkinsci-users@googlegroups.com 
[mailto:jenkinsci-users@googlegroups.com] On Behalf Of Jeffrey Harris
Sent: October-26-16 23:03
To: Jenkins Users
Subject: Suggestions needed

I'm trying to figure out a way to automate submitting a test to our hardware 
testbed and waiting for the test to complete so that the Jenkins job can report 
its status. 

Are either of the ideas below possible?

Create a Jenkins job that submits the test (this is the easy part), waits until 
the job is informed the test is complete and then processes the results. 

The other idea I've had is to create a spool_test job that only spoils the 
test. When the test is complete it starts a complete_test job to process the 
results. 

Ultimately I'd like to have a regress_tests job that spools several tests. But 
I'm not sure with the second approach how to tell regress_tests that it's not 
done until all the complete_test jobs (that it doesn't directly start) are 
done. 

Thanks for any help,
Jeff

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/c7619784-6c20-471f-b727-de7bc57495ca%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/5aaafbbef9dd47cca4abc2d90886539f%40mbx02cmb01p.esentire.local.
For more options, visit https://groups.google.com/d/optout.


Re: Suggestions for using Jenkins for environment deployment?

2014-06-03 Thread Eric Wood
Chandra:

The CI job is a maven job that pulls the code from the SCM (using the TFS 
plugin) and it builds the java asset using maven.  This job then uses the 
post-build Actions step called "Archive for Clone Workspace SCM) to archive its 
workspces for consumption by a downstream job. Also, this job specifies the 
additional post-build Actions step "Build other projetcs (manual step)" to 
specify the downstrean job.

The downstream job uses the "Clone Workspace" for the Source Code Management 
sections.  My deploy takes place using some ANT code calling a REST API for 
Mule as we are deploying a Mule asset to an in-house enterprise service bus.  
All deployment jobs (DEV->TEST->UAT->PROD) in turn use the same "clone archive" 
and "Build other projects (manual step)" to pass the workspace down the 
pipeline. Of course prod does not as it end the pipeline.

The Build pipeline plugin is a visualization tool where you indicate the 
starting job and it visualizes the job relationsheip of upstream/downstream 
jobs.  It allows you to manually trigger downstream jobs based upon the sucess 
of the upstream job.


On Monday, June 2, 2014 6:01 PM, Chanda Norton  wrote:
 


how is this configured?  

On Tuesday, March 4, 2014 7:57:29 AM UTC-5, eric...@rocketmail.com wrote:
I use the build pipeline plugin for this purpose.  The first "link" in the 
chain is a CI build that polls the SCM repo and then subsequent downstream jobs 
are used to promote the build DEV-.>TEST->UAT->PROD
>
>
>
>On Monday, March 3, 2014 2:53 PM, Stephen Connolly  
>wrote:
> 
>The promoted builds plugin is a good starting point.
>
>
>After that it depends where you are deploying your app to.
>
>
>In general, you set up your build to archive the artifacts... Then you set up 
>promotions to move the archived artifacts to their target servers... 
>Parameterized promotions can help if you have to change the target from 
>deployment to deployment.
>
>
>For larger deployments, you are deploying to a file share from which 
>chef/puppet does the actual deployment... But for small deployments you just 
>push direct to the server eg by the ssh/sftp publisher or by a container 
>specific plugin (eg tomcat) or by a PaaS specific deployer plugin (eg 
>cloudbees-deployer-plugin for deployment to cloudbees/cloudfoundry/AWS elastic 
>beanstalk/google app engine)
>
>On Monday, 3 March 2014, Caleb Tote  wrote:
>
>We've been using Jenkins for a year or so as our CI tool, but would like to 
>set it up somehow to also do our environment deployments. I've been testing 
>around with Atlassian Bamboo, which nicely integrates both CI and Deployments; 
>however, we'd like to stay with Jenkins since it's free.
>>
>>
>>Is there a plugin for this type of thing? Any suggestions on how to manage 
>>deployments? Should we just switch to Bamboo?
-- 
>>You received this message because you are subscribed to the Google Groups 
>>"Jenkins Users" group.
>>To unsubscribe from this group and stop receiving emails from it, send an 
>>email to jenkinsci-users+unsubscribe@ googlegroups.com.
>>For more options, visit https://groups.google.com/ groups/opt_out.
>>
>
>-- 
>Sent from my phone
>-- 
>You received this message because you are subscribed to the Google Groups 
>"Jenkins Users" group.
>To unsubscribe from this group and stop receiving emails from it, send an 
>email to jenkinsci-use...@ googlegroups.com.
>
>For more options, visit https://groups.google.com/ groups/opt_out.
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Suggestions for using Jenkins for environment deployment?

2014-06-02 Thread Chanda Norton
how is this configured?  

On Tuesday, March 4, 2014 7:57:29 AM UTC-5, eric...@rocketmail.com wrote:
>
> I use the build pipeline plugin for this purpose.  The first "link" in the 
> chain is a CI build that polls the SCM repo and then subsequent downstream 
> jobs are used to promote the build DEV-.>TEST->UAT->PROD
>
>
>   On Monday, March 3, 2014 2:53 PM, Stephen Connolly <
> stephen.al...@gmail.com > wrote:
>  The promoted builds plugin is a good starting point.
>
> After that it depends where you are deploying your app to.
>
> In general, you set up your build to archive the artifacts... Then you set 
> up promotions to move the archived artifacts to their target servers... 
> Parameterized promotions can help if you have to change the target from 
> deployment to deployment.
>
> For larger deployments, you are deploying to a file share from which 
> chef/puppet does the actual deployment... But for small deployments you 
> just push direct to the server eg by the ssh/sftp publisher or by a 
> container specific plugin (eg tomcat) or by a PaaS specific deployer plugin 
> (eg cloudbees-deployer-plugin for deployment to cloudbees/cloudfoundry/AWS 
> elastic beanstalk/google app engine)
>
> On Monday, 3 March 2014, Caleb Tote > 
> wrote:
>
> We've been using Jenkins for a year or so as our CI tool, but would like 
> to set it up somehow to also do our environment deployments. I've been 
> testing around with Atlassian Bamboo, which nicely integrates both CI and 
> Deployments; however, we'd like to stay with Jenkins since it's free.
>
> Is there a plugin for this type of thing? Any suggestions on how to manage 
> deployments? Should we just switch to Bamboo?
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
> -- 
> Sent from my phone
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-use...@googlegroups.com .
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>   

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Suggestions for using Jenkins for environment deployment?

2014-03-04 Thread Eric Wood
I use the build pipeline plugin for this purpose.  The first "link" in the 
chain is a CI build that polls the SCM repo and then subsequent downstream jobs 
are used to promote the build DEV-.>TEST->UAT->PROD



On Monday, March 3, 2014 2:53 PM, Stephen Connolly 
 wrote:
 
The promoted builds plugin is a good starting point.

After that it depends where you are deploying your app to.

In general, you set up your build to archive the artifacts... Then you set up 
promotions to move the archived artifacts to their target servers... 
Parameterized promotions can help if you have to change the target from 
deployment to deployment.

For larger deployments, you are deploying to a file share from which 
chef/puppet does the actual deployment... But for small deployments you just 
push direct to the server eg by the ssh/sftp publisher or by a container 
specific plugin (eg tomcat) or by a PaaS specific deployer plugin (eg 
cloudbees-deployer-plugin for deployment to cloudbees/cloudfoundry/AWS elastic 
beanstalk/google app engine)

On Monday, 3 March 2014, Caleb Tote  wrote:

We've been using Jenkins for a year or so as our CI tool, but would like to set 
it up somehow to also do our environment deployments. I've been testing around 
with Atlassian Bamboo, which nicely integrates both CI and Deployments; 
however, we'd like to stay with Jenkins since it's free.
>
>
>Is there a plugin for this type of thing? Any suggestions on how to manage 
>deployments? Should we just switch to Bamboo?
-- 
>You received this message because you are subscribed to the Google Groups 
>"Jenkins Users" group.
>To unsubscribe from this group and stop receiving emails from it, send an 
>email to jenkinsci-users+unsubscr...@googlegroups.com.
>For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
Sent from my phone
-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: Suggestions for using Jenkins for environment deployment?

2014-03-03 Thread Stephen Connolly
The promoted builds plugin is a good starting point.

After that it depends where you are deploying your app to.

In general, you set up your build to archive the artifacts... Then you set
up promotions to move the archived artifacts to their target servers...
Parameterized promotions can help if you have to change the target from
deployment to deployment.

For larger deployments, you are deploying to a file share from which
chef/puppet does the actual deployment... But for small deployments you
just push direct to the server eg by the ssh/sftp publisher or by a
container specific plugin (eg tomcat) or by a PaaS specific deployer plugin
(eg cloudbees-deployer-plugin for deployment to cloudbees/cloudfoundry/AWS
elastic beanstalk/google app engine)

On Monday, 3 March 2014, Caleb Tote  wrote:

> We've been using Jenkins for a year or so as our CI tool, but would like
> to set it up somehow to also do our environment deployments. I've been
> testing around with Atlassian Bamboo, which nicely integrates both CI and
> Deployments; however, we'd like to stay with Jenkins since it's free.
>
> Is there a plugin for this type of thing? Any suggestions on how to manage
> deployments? Should we just switch to Bamboo?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to 
> jenkinsci-users+unsubscr...@googlegroups.com
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>


-- 
Sent from my phone

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: Suggestions for CI with Jenkins & Database

2013-12-16 Thread Michael Barbine
https://github.com/mbarbine/JenkinsDB

On Sunday, November 20, 2011 3:46:13 AM UTC-5, julio wrote:
>
> Hi all,
>
> we are starting our development project for the first time with
> Jenkins, and we planned to manage the Database-CI in this way:
>
> 1) every single developer has own database schema+data local as it is
> in the dev-database
> 2) if a developer change locally DDL/DML (in .sql files) and commit
> (we are using GIT), automatically these changes are applied to the Dev-
> Database
>
> Is there a way saying Jenkins applying these changes to the db when
> one or more .sql files are changed? or it should be done via GIT (for
> example in the post-receive hook)?
>
> or there is a better strategy to handle the DB changes?
>
> Thanks
>
> Julio
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: Suggestions...

2013-11-26 Thread Kishore RP
Thanks Stephen for your reply, our jenkins slaves are predominantly 
windows, running a SSH client on windows not sure how reliable it would be, 
we could try pstools but ps tools come with their own perils of network 
issues.
I tried via a Groovy script though, details of which are posted at 

https://groups.google.com/forum/#!topic/jenkinsci-dev/gd7y93o02WA

Could you please let us know your suggestions please on where we are going 
wrong.
Snippet of what i have tried

The groovy script i am using is
+

import hudson.model.*

import hudson.node_monitors.*

import hudson.slaves.*

for (aSlave in hudson.model.Hudson.instance.slaves)

{

  println('');

  if (aSlave.name=="NodeNameTest")

{

  println('Name: ' + aSlave.name);

  println('\tcomputer.kill: ' + aSlave.getcomputer().kill());

  }

}

+

when i run the above the jenkins slave console(jnlp) is not killed but 
keeps trying every 10 seconds :-(, we dont want that to happen, we just 
want to kill the jnlp client and bring it up again once our tests are done.

When i used the below instead of kill, 
 println('\tcomputer.disconnect: ' + 
aSlave.getComputer().disconnect(offlineCause = new 
OfflineCause.ChannelTermination())); 

the jnlp client of slave terminates and reconnects in few seconds.

Thoughts?

Thank you for your help all along


On Thursday, November 21, 2013 6:46:33 PM UTC+5:30, Stephen Connolly wrote:
>
> why don't you turn this on its head somewhat.
>
> have a jenkins job that ssh's into the machine and starts the perf tests.
> The perf tests then publish their results to Jenkins using the "External 
> Job" type which is designed for jobs that are outside of the control of 
> Jenkins but you want to integrate their reporting within Jenkins.
>
>
> On 21 November 2013 13:09, Kishore RP >wrote:
>
>> We cannot afford to run jenkins clients exe on our slaves since they are 
>> used for getting performance metrics, requirement being, when we collect 
>> our metrics(for over an hour) we want the jenkins client to shutdown or go 
>> into a suspended state without taking any system resources
>> however we need jenkins for CI , 
>>
>> One way we are trying to solve the problem is to 
>> offload the client part to a slave manager kind of a machine that will 
>> keep pinging to client machine and jenkins server to keep the communication
>>
>> Any suggestions on how to go about this?
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Jenkins Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to jenkinsci-use...@googlegroups.com .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: Suggestions...

2013-11-21 Thread Stephen Connolly
why don't you turn this on its head somewhat.

have a jenkins job that ssh's into the machine and starts the perf tests.
The perf tests then publish their results to Jenkins using the "External
Job" type which is designed for jobs that are outside of the control of
Jenkins but you want to integrate their reporting within Jenkins.


On 21 November 2013 13:09, Kishore RP  wrote:

> We cannot afford to run jenkins clients exe on our slaves since they are
> used for getting performance metrics, requirement being, when we collect
> our metrics(for over an hour) we want the jenkins client to shutdown or go
> into a suspended state without taking any system resources
> however we need jenkins for CI ,
>
> One way we are trying to solve the problem is to
> offload the client part to a slave manager kind of a machine that will
> keep pinging to client machine and jenkins server to keep the communication
>
> Any suggestions on how to go about this?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: Suggestions...

2013-11-21 Thread Kishore RP
Thank you Stephen, will try the same.

On Thursday, November 21, 2013 6:46:33 PM UTC+5:30, Stephen Connolly wrote:
>
> why don't you turn this on its head somewhat.
>
> have a jenkins job that ssh's into the machine and starts the perf tests.
> The perf tests then publish their results to Jenkins using the "External 
> Job" type which is designed for jobs that are outside of the control of 
> Jenkins but you want to integrate their reporting within Jenkins.
>
>
> On 21 November 2013 13:09, Kishore RP >wrote:
>
>> We cannot afford to run jenkins clients exe on our slaves since they are 
>> used for getting performance metrics, requirement being, when we collect 
>> our metrics(for over an hour) we want the jenkins client to shutdown or go 
>> into a suspended state without taking any system resources
>> however we need jenkins for CI , 
>>
>> One way we are trying to solve the problem is to 
>> offload the client part to a slave manager kind of a machine that will 
>> keep pinging to client machine and jenkins server to keep the communication
>>
>> Any suggestions on how to go about this?
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Jenkins Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to jenkinsci-use...@googlegroups.com .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: Suggestions for advanced git/jenkins build integration

2013-05-21 Thread Stuart Montgomery
Comments inline…

On May 21, 2013, at 3:15 PM, "Owen B. Mehegan"  wrote:

> My team has 30+ git repos, which all use the same post-receive hook to 
> trigger Jenkins build jobs when people push a commit to the 'master' branch 
> (the hook maintains a mapping of repo -> Jenkins job). Work done in any other 
> branch does not trigger a build automatically, but developers can build their 
> branch using the Jenkins UI - 'branch' is a string parameter for all jobs.
> 
> All of our build jobs also have a list parameter of "deploy environment" 
> which, if selected, causes the job to build a package and push it to an 
> environment for test. But our workflow doesn't lend itself to continuous 
> deploy (yet), so most people commit, then go to the Jenkins UI and do another 
> build with the deploy option set if they want a deploy. This is obviously 
> wasteful since it performs the build steps twice, unnecessarily, and requires 
> a change of context when someone wants their commit to go to a test env.
> 
> People are asking me for an easier way to specify that a commit should be 
> deployed. The ideal solution seems to involve mind-reading, which is not yet 
> supported by any Jenkins plugin I've seen. I'm curious if anyone has come up 
> with a good workflow for this. We have a couple of possible solutions, but 
> haven't tried any yet:
> 
> * Some 'magic phrase' in the commit message, which is parsed by the 
> post-commit hook. This pattern is sometimes used by code review or bug 
> tracking systems, but I don't love the idea of adding this type of metadata 
> to the commit text.
> * Every repo has a branch named for each test environment (we have several), 
> and if people want to deploy to that env, they merge to that branch and push.

I prefer this approach, especially compared to the next idea of using tags. 
Branches conceptually lend themselves to being a "moving target", whereas tags 
(using `git tag -f`) seems less fitting since most of the time, a the ref a tag 
points to should not change.

And if you used branches and only want a subset of contributors to have access 
to deploy to certain environments, you could enforce branch-specific security 
requirements using a Git hook script.

> * Every repo has a git tag named for each test environment, and people update 
> the tag with 'git tag -f' when they want to trigger a deploy.
> * Every repo contains a file which defines some parameters that are 
> interpreted by the post-receive hook. Branches can then do different things. 
> But at best this gives us branch-level resolution, and people are asking for 
> commit-level. Also I dislike the idea of magic files in a repo driving 
> build/deploy behavior. Seems like it's overloading things.
> * People just stop complaining and use the damn Jenkins UI.

You could also use the Jenkins CLI or REST API to write a script to trigger a 
"deployment" job, if people wanted to avoid using the Jenkins UI.

> I would welcome any other suggestions, or thoughts about the ones we have 
> come up with! Thanks in advance :)
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

Stuart

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.