Skip to content
Snippets Groups Projects
Select Git revision
  • VT-109-restructure-spack
  • VT-106-pypi-release
  • dev protected
  • master default protected
  • VT-87-Enabling-coverage-report-for-the-dedal-respository
  • VT-70-function-Migrate-Spack-env-setup-into-ESD-repo-with-buildcache
  • koutakia protected
  • oci_cache
  • image_testing
  • ebrains_testing
10 results
Compare History
Philipp Spilger's avatar
Only cleanup at end of job
Philipp Spilger authored 
* allows using the repos cloned into the workspace beforehand for
  gerrit notifications, required for checkout via waf because there
  the repos reside in the workspace and would be deleted prematurely
  without this change
* requires contiguous allocation of an agent, but the verification
  is not dominating anymore, therefore not much parallelization
  drawback expected

Change-Id: I06f8b826303fbf34dd58b026f7270eed6ab1b870
ee8073b3
Name Last commit Last update
.ci
misc-files
tests
utils
.gitreview
README.md
container-build-files
wscript
README.md

Yashchiki

Visionary container image build flow. This repository contains code and CI configuration files to build a singularity-based container image containing all visionary software dependencies. Currently two different images are generated: firstly, a standard image for experimenting/modeling, software development and related activities with BrainScaleS and other systems — software is provided by a Spack-based installation process; secondly, an ASIC-image providing an environment for ASIC-related tools (RTL simulators, etc.). The CI flow (via Jenkins) integrates into Gerrit (Code-Review tool) for triggering container image builds as well as software builds based on testing container images.

Supported keywords in gerrit message

NOTE: These options are to be specified in the gerrit COMMENT message, NOT in the git COMMIT message!

The idea is that, often times, these modifiers are just temporarily attached to a single build rather than a complete change.

BUILD_THIS

Start a yashicki build with this change as toplevel.

WITHOUT_FAILED_CACHE

If a testing build fails, link all preserved packages and the current build cache to a new temporary build cache under failed/c<num>p<num>_<num>.

Behaviour for testing builds triggered from gerrit:

  • Unless the user specifies WITHOUT_FAILED_CACHE in the gerrit commit, check if there is a failed build cache for this changeset that was created as described above and use the latest one as build cache for the current build.
  • The user can also supply WITH_CACHE_NAME=<name> to specify a different build cache to be used for this build.

WITH_CACHE_NAME=<name>

Use /home/vis_jenkins/build_caches/<name> on conviz as buildcache instead of the default one. Can also be used for failed caches.

WITH_SPACK_{CHANGE,REFSPEC}

Since often times yashchiki and spack changes are tested together but have no real dependency on one another, we misuse the Depends-On mechanism in the commit message to build a container with a specific spack and yashchiki changeset.

You can use:

  • WITH_SPACK_CHANGE=<change-num> to use the latest patch set of the given spack changeset for the build
  • WITH_SPACK_REFSPEC=<refspec> to specify a complete spack refspec that is to be used for this build (i.e., refs/changes/<change-num[-2:]>//) to have full control over which changeset/patch level to build.

These take priority over commit-specified Depends-On: and are mutually exclusive with jenkins-specified build parameters since each build gets either triggered manually in jenkins or via gerrit.

WITH_DEBUG

Specifying WITH_DEBUG in the triggering comment will enable debug output.