Skip to end of metadata
Go to start of metadata

You are viewing an old version of this content. View the current version.

Compare with Current View Version History

« Previous Version 17 Next »

 

This page should be used to collect ideas to shape Kieker's delivery pipeline

 

Pipelines

Pull request

Executed for a pull request of a branch to master issued via GitHub. A merge request can be accepted only if this pipeline executes successfully.

Pipeline on Snap-CI: https://snap-ci.com/github_repositories/kieker-monitoring/kieker/pulls

Feature branch

A pipeline for a branch is instantiated for each branch with a prefix issue- (e.g., issue-1432) and triggered for each subsequent commit.

Example pipeline on Snap-CI: https://snap-ci.com/kieker-monitoring/kieker/branch/issue-1432

Master to stable

Executed for each commit into the master (possible via a pull request only). The final stage of the pipeline is a push to the stable branch.

Pipeline on Snap-CI: https://snap-ci.com/kieker-monitoring/kieker/branch/master

Nightly release

Executed each night based on the stable branch. 

Stages: Corresponds to Master to stable followed by the micro-benchmark.

Nightly release artifacts are available via https://build.se.informatik.uni-kiel.de/jenkins/job/kieker-nightly-release/lastSuccessfulBuild/artifact/

Pipeline on Jenkins: https://build.se.informatik.uni-kiel.de/jenkins/job/kieker-nightly-release/

Release

Executed (manually) to create release candidates and, finally the release, from the respective release branch.

Stages: Corresponds to Master to stable

Release (candidate) artifacts are available via https://build.se.informatik.uni-kiel.de/jenkins/job/kieker-RC-release/ws/build/

Pipeline on Jenkins (deactivated during non-release periods): https://build.se.informatik.uni-kiel.de/jenkins/job/kieker-RC-release/

Kieker Build Docker Containers

As Snap-CI supports Docker, we created Docker containers to have a reproducible build environment.

The repository containing all the Dockerfile files: https://github.com/kieker-monitoring-docker/kieker-build

The DockerHub containing the automatically built containers: https://hub.docker.com/r/kieker/kieker-build/

The most important tags right now are:

  • kieker/kieker-build:base (Base image for all other containers based on Ubuntu 15.10 and the additional R dependencies)
  • kieker/kieker-build:openjdk6 (Based on :base with openjdk-6 installed)
  • kieker/kieker-build:openjdk7 (Based on :base with openjdk-7 installed)
  • kieker/kieker-build:openjdk8 (Based on :base with openjdk-8 installed)
  • kieker/kieker-build:snap-ci-build (Based on :openjdk6, assuming that the kieker repository to build is mapped to /opt/kieker inside the container and executes the Gradle wrapper with the build task by default)
    To execute it locally:

    sudo docker run -t -i -v /path/to/kieker/repo:/opt/kieker kieker/kieker-build:snap-ci-build

  • kieker/kieker-build:snap-ci-nightly (Based on :openjdk6, assuming that the kieker repository to build is mapped to /opt/kieker inside the container and executes the Gradle wrapper with the jenkinsNightlyBuild task by default. In addition to the :snap-ci-build container, this container has all packages installed that are needed to run the nightly build; e.g., pdflatex, bibtex, fonts for documentation generation)
    To execute it locally:

    sudo docker run -t -i -v /path/to/kieker/repo:/opt/kieker kieker/kieker-build:snap-ci-nightly

Some Todos

Pipeline template not only for the Kieker core but also for other projects in the "Kieker orbit"

  • Test with different versions of Java (6?, 7, 8)
  • No artifact is being rebuild. In each stage after the build stage, the build artifacts from the build stage are used.
  • Does it make sense to have a stable branch in addition to master into which only those changesets are merged that passed the entire pipeline?
  • Do we want to have a gatekeeper condition (threshold) on the regression benchmark?
  •  Separate the unit tests from the integration tests
  • Insert the call of the check-script (in the stage around the acceptance test?)
  • Merge the Gradle threshold code into master to be able to have quality gates for code analysis
  • Think about a way for continuous build numbering without breaking sonatype/maven conventions (we could use the build numbering in snap-ci to do so)

  • No labels