Ok I think I have a valid solution
I left things pretty much the way they were, but excluded most of the plugin
executions that would usually kick in in the deploy step.
Now it seems as only the steps we want are executed. I definitely like this now
as now we are really only deploying things if all tests pass.
So now untested code in an upstream module can't break everything downstream.
Unfortunately we additionally had a second problem: Fontawesome 5 was released
recently and therefore the download of 4.7 was discontinued and this caused the
build to fail. I removed the dependency to that as I could not trace down any
usage of this anywhere in the generated site. This also greatly reduces the
amount of stuff having to be deployed.
Please have a look at my changes.
Chris
Am 28.02.18, 09:22 schrieb "Christofer Dutz" <christofer.d...@c-ware.de>:
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
