Hi Patricia, We are also looking the same solution. Can you please let us know how you have achieved below task: 1. How you are making sandbox=true builds ,which plugins you are using to achieve this? 2."a user can also pick a smaller subset of these tests" how you have achieve this? If possible can you share jenkins project snapshots and configuration details.
Thanks in advance. On Thu, Oct 16, 2014 at 2:52 AM, Patricia Wright <[email protected]> wrote: > Here is how we accomplish this. > > We have a master job that runs all tests. > That job gets called one of two ways: > We have done this, but it has repercussions for every job out there. > It's probably more complicated than you'd think. > > A high level overview, is that we have a master job that calls all of the > tests. > > This master job is called one of two ways: > * the standard revision control polling compile job. (Normal continuous > integration) > > * a user form, where someone can specify the location of the uncommitted > changes. we call these "sandbox builds" > the sandbox test job downloads the results of the users changes and > injects them into the system with the additional parameters so that we can > tell difference between normal tests and sandbox tests. (a user can also > pick a smaller subset of these tests) > > We've done extensive reporting modifications so that jobs with > "SANDBOX=True" as a parameter are ignored as part of normal reporting, and > i've set it such that developers do not get emails when 'sandbox job' tests > fail - only the submitter of the original sandbox job does instead. > > We typically use this for major changes to the code base rather than > run-of-the mill features and fixes. > > The other option is to make a second Jenkins environment, but then you > have to sync the tests, and have more (virtual) hardware utilization.. > Pick your poison. > > ________________________________________ > From: [email protected] <[email protected]> > on behalf of Les Mikesell <[email protected]> > Sent: Wednesday, October 15, 2014 3:19 PM > To: jenkinsci-users > Subject: Re: ask for files before build > > On Wed, Oct 15, 2014 at 1:36 PM, niraj nandane <[email protected]> > wrote: > > Yes i want to check changes before checkin > > > > Can't you just do a build on your local machine where you are doing > the work? Why does jenkins need to be involved at this point? Or > alternatively, why not commit to a branch that won't affect others for > a jenkins build and only merge the work if the build succeeds? > > -- > Les Mikesell > [email protected] > > -- > 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 [email protected]. > For more options, visit > https://urldefense.proofpoint.com/v1/url?u=https://groups.google.com/d/optout&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=P%2FDbhm7GMaM%2FtPTZjlK%2F8lebpERVSZcf2B%2BqCod7tGs%3D%0A&m=HB4AAmkSIupknPm8QxNq4Q%2FCpcaIbYMUiPHi7aNpAE0%3D%0A&s=55a38c84d9a3218b0b75b727284f89856bc630ab8cc048fe1abb4ad644140b12 > . > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Jenkins Users" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/jenkinsci-users/p7wU_66T76M/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- Thanks and regards-- Niraj Nandane(Vit pune) -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
