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<mailing.list.collect...@googlemail.com>
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.
