|
Hi there,
I'd like to set up two dependent build projects for the same software product as follows: - have a "quick" build run every time a developer commits changes, i.e. using the SCM polling trigger. This will only be an incremental build, followed by unit tests. - run a scheduled full "nightly" build using the full test suite, setup creation etc. once a day using the same SCM revision number as the last successful/stable "quick" build (if there is one, and if that revision number has increased since last time the "nightly" build ran). I wonder how this could be archived? My current understanding is that it's hard to mix these two concepts in Jenkins. I know about the Parameterized Trigger plugin which covers the "use the same SCM revision number" requirement, but not the requirement of running only once a day. Thanks! |
|
On 23.02.2012 08:36, Sason wrote:
> Hi there, > > I'd like to set up two dependent build projects for the same software > product as follows: > - have a "quick" build run every time a developer commits changes, > i.e. using the SCM polling trigger. This will only be an incremental > build, followed by unit tests. > - run a scheduled full "nightly" build using the full test suite, > setup creation etc. once a day using the same SCM revision number as > the last successful/stable "quick" build (if there is one, and if that > revision number has increased since last time the "nightly" build > ran). > > I wonder how this could be archived? My current understanding is that > it's hard to mix these two concepts in Jenkins. I know about the > Parameterized Trigger plugin which covers the "use the same SCM > revision number" requirement, but not the requirement of running only > once a day. > > Thanks! > revision number in a file, which is archived as artifact. The nightly job just copy the archived file from the latest stable build of the quick job, and begin to build the same revision number. The nightly job may have some logic to check whether the latest stable revision number has been built (again, this can be done by archiving artifact and copy artifacts plugin). Or this logic can be isolated in an intermediate job that checkes the stable revision number of the quick job and trigger the nightly build if necessary. |
|
Thanks John, that sounds like a good idea. I'll see what I can do by
way of archiving artifacts. So far, I had been thinking of artifacts in term of pure build output (files, libraries, whatever), not as metadata. On 23 Feb., 23:56, John Vacz <[hidden email]> wrote: > On 23.02.2012 08:36, Sason wrote: > > > > > > > > > Hi there, > > > I'd like to set up two dependent build projects for the same software > > product as follows: > > - have a "quick" build run every time a developer commits changes, > > i.e. using the SCM polling trigger. This will only be an incremental > > build, followed by unit tests. > > - run a scheduled full "nightly" build using the full test suite, > > setup creation etc. once a day using the same SCM revision number as > > the last successful/stable "quick" build (if there is one, and if that > > revision number has increased since last time the "nightly" build > > ran). > > > I wonder how this could be archived? My current understanding is that > > it's hard to mix these two concepts in Jenkins. I know about the > > Parameterized Trigger plugin which covers the "use the same SCM > > revision number" requirement, but not the requirement of running only > > once a day. > > > Thanks! > > I think you can use copy artifacts plugin. The quick build job write its > revision number in a file, which is archived as artifact. The nightly > job just copy the archived file from the latest stable build of the > quick job, and begin to build the same revision number. The nightly job > may have some logic to check whether the latest stable revision number > has been built (again, this can be done by archiving artifact and copy > artifacts plugin). Or this logic can be isolated in an intermediate job > that checkes the stable revision number of the quick job and trigger the > nightly build if necessary. |
|
Yes, we actually do generate (one single) metadata file during the main
build job, this metadata is archived, and passed through the whole pipeline, to other downstream jobs, promotion jobs etc. With this metadata file being fingerprinted, you get a very nice side effect, that Jenkins can figure out all the job dependencies automatically. On 24.02.2012 08:08, Sason wrote: > Thanks John, that sounds like a good idea. I'll see what I can do by > way of archiving artifacts. So far, I had been thinking of artifacts > in term of pure build output (files, libraries, whatever), not as > metadata. > > On 23 Feb., 23:56, John Vacz<[hidden email]> > wrote: > >> On 23.02.2012 08:36, Sason wrote: >> >> >> >> >> >> >> >> >>> Hi there, >>> >> >>> I'd like to set up two dependent build projects for the same software >>> product as follows: >>> - have a "quick" build run every time a developer commits changes, >>> i.e. using the SCM polling trigger. This will only be an incremental >>> build, followed by unit tests. >>> - run a scheduled full "nightly" build using the full test suite, >>> setup creation etc. once a day using the same SCM revision number as >>> the last successful/stable "quick" build (if there is one, and if that >>> revision number has increased since last time the "nightly" build >>> ran). >>> >> >>> I wonder how this could be archived? My current understanding is that >>> it's hard to mix these two concepts in Jenkins. I know about the >>> Parameterized Trigger plugin which covers the "use the same SCM >>> revision number" requirement, but not the requirement of running only >>> once a day. >>> >> >>> Thanks! >>> >> I think you can use copy artifacts plugin. The quick build job write its >> revision number in a file, which is archived as artifact. The nightly >> job just copy the archived file from the latest stable build of the >> quick job, and begin to build the same revision number. The nightly job >> may have some logic to check whether the latest stable revision number >> has been built (again, this can be done by archiving artifact and copy >> artifacts plugin). Or this logic can be isolated in an intermediate job >> that checkes the stable revision number of the quick job and trigger the >> nightly build if necessary. >> |
| Powered by Nabble | See how NAML generates this page |
