ASWF CI Working Group
Meeting: 21 August 2019
- Daniel Heckenberg (Animal Logic, TAC Chair)
- Jean-Francois Panisset (VES Technology Committee)
- Michael Dolan (SPI / OCIO Representative)
- Doug Walker (Autodesk)
- Jeff Bradley (Dreamworks)
- Aloys Baillet (Animal Logic)
- Larry Gritz (SPI)
- Brian Cipriano (Google / OpenCue)
- Gordon Bradley (Autodesk)
- CI Documentation, Guidelines
- Solidify the work we have done so far
- Dependency management
- CMake find modules
- Does this make most sense in CI context of a broader one
- Not that much progress on “top of tree builds”, may change the approach from the current “pre built image”
- Should we identify the tree of dependencies, ASWF / Ref Platform components
- To whom would these top of trees be useful, if at all? If no one is looking at those builds, then they aren’t helping.
Gordon: leading into SIGGRAPH we talked about taking a “data driven approach”, asking the official members of the foundation as to what our goals should be. Did that happen / get done? Daniel: some of the data from the Open Source day was posted, but no official work to target the ASWF members. Gordon: what are the priorities that would “move the needle” for the second year after what got done the first year. Also getting feedback from the Governing Board. Daniel: that’s a very relevant activity, specific question of “top of tree builds” isn’t useful to anyone outside the project, so if anyone in this group isn’t interested, no point in doing it. But for the other ongoing activities, we have good feedback from the projects and the members that this is useful work. Gordon: should we take some time to define “success” so we are clear on what we are driving at. Larry: once a week top of tree across the projects would make sure that the projects haven’t drifted apart from each other API wise. Michael: OCIO has a weekly “top of trunk” build against its dependencies to make sure they don’t get surprised by changes in dependent projects. Some bash trickery to figure out the “latest” tag for those projects. Daniel: this could make sense to generalize across all the projects, or could be centralized to have cross project builds happen. Michael: will send via email. Larry: could be part of best practices document, we don’t necessarily need a complete separate process to do this.
- Commercial components
- All 3 of these requirements have been reinforced by the Governing Board. We have support for Houdini, but we should aim to take this further.
- Is there value in trying to do this in context of CI, or have it happen in the individual projects?
- Are there resources outside the projects? Aloys doing work on Docker images for instance.
Aloys: has anyone have ideas in terms of staging strategies for Docker images? Was going to create a branch called “staging” for ASWF Docker which is where devs would create branches / PRs, only a manual merge to Master would create the official ASWF staging images. Does this sound like a good idea? Also, what is success for this project? At this stage used by all the Linux builds. GPU is next step.
Making use of Azure Pipelines caching to accelerate builds, but system is still in preview, and is not very flexible, no “fallback caching” available, either you get what you ask for, or nothing at all.
Happy to build images with Java JDK for OpenCue.
Next stage would be to use package manager such as Rez? Rez seems to be focussing on C++ building (as per SIGGRAPH BoF). Aloys: lack of fine grained control such as debug builds is an issue with Rez. Jeff: experimenting with fairly static definitions of debug vs opt builds under Rez. The features being presented at the BoF seemed to be quite complex.
- Aloys: also artifact management: Conan has functionality for that, AL has done some work to integrate Rez with Artifactory, looking at perhaps contributing that back.
- Investigate GitHub Actions CI?
- Has anyone taken a look at it?
- Larry: closed beta, asked for early access, but no response yet.
- Aloys: hasn’t showed up in the UI yet
- Michael: YAML syntax looks very similar, shared infrastructure with Azure Pipelines.
- Larry: one stop shop offering for GitHub, not a pressing issue, but could be interesting for a future project.
- Daniel: quick take seems that it isn’t quite ready for general use (“don’t use for production critical projects”), shifting to a different configuration language (HCL to YAML, which looks identical to AP YAML). Eventually may offer better GitHub infrastructure, avoiding extra layers of administration / access rights.
- Standardization of additional dependencies?
- OpenCue: JDK
- Trying to standardize on ASWF Docker images, but missing some components.
- Should we specifiy a range of versions that things should build against.
- Java 8, Cmake
- Not in VFX Reference Platform (Daniel), but still important
- Brian: can forge ahead, and provide expertise as they learn
- Brian: Was unable to install new packages in Docker images? Michael: was able to install on top of those images using “sudo yum install” (Aloys)
- Aloys: Docker images in the repo, there’s a Docker image for each project that is there to add additional components, so could create one for the OpenCue project so they don’t need to do this in their build. Brian: will send a PR for that.
- Michael: “latest revision” infrastructure for external dependencies uses the common Docker image.
- OpenCue: JDK
- Daniel: lots of work from Christina doing many builds on many platforms.
- Brian: running on Azure Pipelines, trying to standardize on VFX Reference Platform, moved SonarCloud instance to ASWF one.
- Michael: outstanding CI need is GPU support. Has the Governing Board approved any funds for GPU instances? Daniel: in principle yes, there was originally a large budget for CI infrastructure, we should go ahead with a specific proposal. JF: Do Mac builders have GPU enabled by default?
- Gordon: GPU support should be more precisely defined, what are we trying to achieve? Daniel: CUDA versions, GPU hardware, OpenGL / Metal / …
- Larry: being able to test against at least a couple of GPU configurations would be important.
- No representatives
- No representatives
- Organisations, Roles, Access
- Productive discussion at last TAC meeting.
- Current system only really works for repos that are part of ASWF organization, a couple of projects haven’t transitioned yet. So they have to set up duplicate services.
- How do we decentralize access / roles / …
- This has been a bit of a friction point, slowing down experimentation / progress. Would the steps outlined in the TAC meeting be sufficient? Any anecdotal feedback from individual developers working with the CI system?
- JF: Does it make sense to create “dummy / sandbox” fork repos in the ASWF organization to be able to leverage Azure Pipelines / SonarCloud / … Michael: seems like it could be useful?
- Michael: would be useful to have a boiler plate / Hello World project, with a documentation README for things like SonarCloud, Azure Pipelines…
- Daniel: agreed, the “teapot” version of a project.
- A sample project would be a concrete deliverable.
- Once every 4 weeks?
- Daniel: does this make sense, moving CI work to the projects, leaving room for other TAC projects?
- Gordon: seems to make sure, especially if CI group is more about overseeing the work done in the projects.
- $100 test for CI efforts (Gordon)
- Share “latest tag” cross project build example from OpenColorIO (Michael)
- CI Documentation / sample project (JF)
- Follow up meeting:?