Skip to content
Snippets Groups Projects
Select Git revision
  • 381f68f92d9d75bccb8d67ea118a47d4f75a4818
  • master default protected
  • spack-compatible-0.23.1
  • dev protected
  • dedal-py-39
  • ECM_testing
  • VT-109-restructure-spack
  • 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
  • Dedal@1.0.0
  • Dedal@0.9.1
  • Dedal@0.9.0
16 results

dedal

Eric Müller's avatar
Eric Müller authored
Depends-On: 15326
Change-Id: I372fa9501be04c7167ea181f822174cc132ecca9
381f68f9
History

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.