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
https://jenkins.aswf.io/ 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
https://jenkins.aswf.io/sandbox 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:
Nexus
Sonatype Nexus located at
https://nexus.aswf.io/ 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
Jira located at
http://jira.aswf.io/ 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.
Example:
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.
