Ok,
bringing back the discussion I just had with Sebastian (has problems accessing
the mailing list at his current customer).
I see the following problems with the current build pipeline:
1. The second "deploy" execution runs the build and tests double
2. The site should be generated on the same node as the tests are run
(currently not happening when using the Site-Generation Job, but should be)
The reason Sebastian split up "Build & Test" and "Deploy" was to prevent things
being deployed if the tests fail, which makes sense.
I would propose to re-unite the build, test, site-generation and sonar-analysis
to one step (Maven is built to handle all of this, I see no benefit in
splitting this up).
Additionally we activate the experimental "deployAtEnd" switch of the deploy
plugin. This should only deploy anything if all modules builds are finished and
the deploy phase of the last module is executed.
What do you think?
Chris
Am 27.02.18, 18:43 schrieb "Christofer Dutz" <christofer.d...@c-ware.de>:
By the way,
as it seems there is no clean solution to be able to run the rawsockets
tests without a dedicated VM, I ordered one from infra today.
This VM can be configured to our needs and we no longer have to jump any
hoops. This VM will be a Jenkins node (probably labeled plc4x) which is only
available to our projects build jobs. If we need anything installed, we can add
it to the puppet scripts for it and the changes will get deployed.
I really hope this way we'll get rid of some of the most annoying problems
we were fighting with and keep the build simple at the same time.
The option of building docker images for running integration-tests sounded
extremely complicated from my point of view.
The option to not execute the raw socket tests is not really an option, I
think as I think the main CI server should execute all tests and not just a
subset.
Chris
Am 27.02.18, 18:15 schrieb "Christofer Dutz" <christofer.d...@c-ware.de>:
Hi Sebastian,
I just noticed two things with the new piepeline. It now correctly is
able to deploy the site from the main build, so that's cool.
Unfortunately it seems that now the site is no longer able to generate
the images in via blockdiag etc.
Also I did notice that the split between build and deploy has a very
undesirable side effect:
- Build does a "clean install", which does clean, compile, test,
integration-test
- Deploy does a "deploy", which does compile, test, integration-test,
deploy
So most of the build is executed twice, we should eliminate that,
however I don't think Maven likes this sort of split-up and I doubt a "mvn
deploy:deploy" will automatically know what to deploy.
Right now I would suggest to bring the deploy back to the "build
master" as it's only deployed when built on master.
Chris
Am 24.02.18, 16:55 schrieb "Christofer Dutz"
<christofer.d...@c-ware.de>:
Hi Sebastian,
I finally managed to have my flu-infected brain have a look at the
changes. I do agree it l looks a lot cleaner this way. I also like the way the
Jenkins jobs now look.
Hopefully now we could also do the following things:
- Add a "site-deploy" step that is only executed on the master
branch, which deploys the site. In order for this to work, we would need to
enforce this part being executed on a node tagged with "git-websites" as only
these can actually push to the git-site branch.
The second thing is a little more complex:
- In order to run the RawSocket tests, we need to have libpcap with
setuid root or have to execute the tests as root. Both is not possible on the
normal Jenkins VMs for good reasons. There would however be an option to fire
up a Docker container and run the tests inside that. Unfortunately I need a lot
of help with setting up something like that (Ideally this would be handled in
Maven and not in the Jenkinsfile, as this way the test-results and coverages
are cleanly integrated with the rest of the build)
Seems the docker-maven-plugin from Fabric8 would be a possible
solution, but I remember that Fabric8 has been cancelled by RedHat ... would it
still be ok to use that plugin?
http://info.michael-simons.eu/2016/08/25/integration-testing-with-docker-and-maven/
Chris
Am 22.02.18, 13:02 schrieb "Sebastian Rühl"
<sebastian.ruehl...@googlemail.com>:
Hi Together,
Today I found the time to move from scripted pipeline to
declarative pipeline.
This opens a much better integration into Jenkins and makes the
Jenkinsfile much more readable.
Small changes to before:
- The build stage is split into two (Build, Build master) where
I converted the if statement to stage conditions.
- Testsresults are reported to Jenkins and can now easily be
seen in the build view
- Toolmanagement is moved to native integration (so no need for
explicitly defining envs anyomore)
What I want to do next is to use the native sonar integration.
This will then use the sonar configuration defined in Jenkins and ad a sonar
link into Jenkins. Then we also could define a build-breaker for quality gates
in the future.
Sebastian
