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
