ASWF CI Infrastructure: VFX Reference Platform Dependencies

Daniel Heckenberg

Hello everyone,

As we start to adopt projects into the ASWF, I would like to turn attention to the CI setup and especially the way that project dependencies are built and managed.

There have been many discussions here and elsewhere which I shall ambitiously summarize as, "We should make the ASWF CI dependencies a practical realization of the VFX Reference Platform."   This would entail establishing build configurations for the relevant packages to be built from source and storage of the results as reusable artifacts.  As all parts of this chain will be open, accessible and reproducible this offers a great opportunity for contributions from the community, and for the configurations and artifacts to be used to facilitate software development and OSS software use.

Of course, there are lots of gaps and questions with this, such as "what do we do for non-Linux builds"?  I'd like to encourage the discussion here as we embark on the effort.

Some links follow with excellent Linux Foundation documentation of the CI infrastructure.

Daniel Heckenberg

ci-management repo here:
CI docs are available here:

As a background into the current ASWF CI infrastructure, Thanh Ha gave a great overview back in July:

CI Infrastructure Usage Details

Thanh Ha
Jul 31  

Hi Everyone,
The infrastructure for ASWF is ready to go and has the following components:
I will step through each of those components one by one below:
GitHub Organization
The current organization has 4 repos: ci-management, opencolorio, openexr, and openvdb.
The 3 project repos are just forks of their respective upstream projects. The "ci-management" repo contains the code for the CI system, mainly all of the Jenkins build scripts. It contains 3 important directories:
1. jenkins-config: contains Jenkins global configuration, usually not too important for contributors and is typically maintained by the releng team
2. jjb: contains the project build scripts, usually maintained by the releng team & projects
3. packer: contains the vm image build scripts, we try to make reproducible CI so that any org can take the same packer scripts and build the same VM Images in their own environments.
Projects typically will be most interested in the "JJB" directory and detailed documentation on Jenkins Job Builder (JJB) / Jenkins usage are available at these 2 links:
Jenkins Job Builder is a tool that allows projects to manage their Jenkins Job configuration using YAML configuration files typically stored in a Git repo so that it can be source controlled the same way as code.
When a Pull Request is merged in the ci-management repo a Jenkins job will kick off and automatically update all of the Jenkins jobs in the production system with the updated build configuration.
Jenkins / Jenkins Sandbox
We provide 2 Jenkins servers for projects to utilize the first is the production Jenkins system located at which is where all the production builds are run (the jobs that report back to GitHub). We do not allow developers to login and manage Jenkins in the production system, this is purely managed via the ci-management repo mentioned previously.
The 2nd system is the Jenkins Sandbox located at is for projects to develop new job types and test their jobs before merging the patch into the ci-management repo and making it live to GitHub.
Detailed documentation on how to use the Jenkins Sandbox is available here:
Sonatype Nexus located at is where all of our build artifacts / binaries are released to. Typically a "staging" job will produce a staging repository in Nexus containing a Release Candidate build. Projects can then test this repository and once approved will be released to a "release" repository in Nexus to make it widely available.
Jenkins jobs typically manages the staging repository creation and LF Helpdesk will manage the release (we are working on some automation here for the future).
Jira located at can be used to track bugs and new feature development. We've created Jira projects for the 4 repo projects already ci-management, opencolorio, openexr, and openvdb.
Jenkins Jobs
With that said I'd like to discuss some Jenkins jobs we've rolled out already for the projects. For every project we have 2 job types "verify" and "stage".
The "verify" jobs are used to verify code contributions from contributors by running test build of the project. Typically it will also run any unit tests etc... as configured by the project for the build. This job also watches GitHub for keywords so if someone leaves a comment "recheck" in a PR comment the job will automatically retrigger for that PR. This is useful for rerunning the verify tests in case of intermittent issues.
As an example we've configured the OpenEXR project to run 2 verify builds for incoming PRs. One job runs autoconf build and the other job runs CMake build, this allows us to test both supported build methods simultaneously for all incoming PRs.
The "stage" job type produces release candidate builds. The idea is that this job can run periodically and a project can decide to release any particular day's "staged release" as the final release. The job stores a commit hash of the build so that the developer can tag the appropriate commit as was built by Jenkins after approving a staged release.
For example:
This job produced a staging repo "opencolorio-1002" here:
This is a temporary repository containing the artifacts for the release. Once a project decides to release this repo it will be copied to the final release repository here:
Making the artifacts in that staging repo available generally to the world.
This was a quick walkthrough of the current CI infra. It is a lot to cover all at once but please feel free to reach out with any questions about this system.

Join to automatically receive all group messages.