> On Nov 14, 2017, at 9:17 AM, Thomas Bouron <[email protected]> wrote:
>
> 1. In Jenkins, rather than using a maven type job, I'm using a freestyle type
> job to call `docker run .... ` during the build phase. Is it the right way to
> go?
All of the projects I’m involved with only ever use freestyle jobs.
Soooo… :)
> 2. My docker images are based on `maven:alpine` with few extra bits and bobs
> on top. All is working fine but, how do I configure jenkins to push built
> artifacts (SNAPSHOT) on Apache maven repo? I'm sure other projects do that
> but couldn't figure it out so far.
This is one of the few jobs that Apache Hadoop doesn’t have dockerized.
I think I know what needs to happen (import the global maven settings) but I
just haven’t gotten around to building the bits around it yet. I’ll probably
write something up and add it to the Apache Yetus toolbox.
> 3. Each git submodule requiring a custom docker image will have their own
> `Dockerfile` at the root. I was planning to create an extra jenkins job to
> build and publish those images to docker hub. Does Apache has an official
> account and if yes, should we use that? Otherwise, I'll create an account for
> our project only and share the credential with our PMCs.
I’m personally not a fan of depending upon docker hub for images. I’d
rather build the images as part of the QA pipeline to verify they always work,
and if the versions of bits aren’t pinned, to test against the latest. This
also allows the Dockerfile to get precommit testing.
It’s worth mentioning that all of the projects I’m involved with use
Yetus to automate a lot of this stuff. Patch testing uses the same base images
as full builds. So if your tests run frequently enough, they’ll stay cached and
the build time becomes negligible over the course of the week.
As I work on getting the Yetus jenkins plug-in written, this will
hopefully be dirt simple for everyone to do without spending any time really
learning Yetus.
