Skip to content

Latest commit

 

History

History
123 lines (69 loc) · 14.8 KB

2021-10-13.md

File metadata and controls

123 lines (69 loc) · 14.8 KB
parent title
Meetings
2021-10-13

ASWF CI Working Group

Meeting: 13 October 2021

https://zoom.us/j/757849640?pwd=QzE1K2hrL2FHSFhKK3h5Z3BWTFJsZz09

Attendees

  • Jean-Francois Panisset (VES Technology Committee)
  • Aloys Baillet (NVIDIA)
  • Larry Gritz (Sony Imageworks)
  • Sergio Rojas (Arena World)
  • Andrew Grimberg (LF RelEng)
  • Patrick Hodoul (OCIO / Autodesk)
  • Ryan Botriell (spk / ILM)
  • Trevor Thomson (Intel)
  • Arun Ramachandran
  • Fabrice Macagno (Animal Logic)
  • Jeff Bradley (DreamWorks)

Apologies

New items

  • Welcome Arun, Pipeline TD, developing VFX software

  • CI WG standalone repo now at https://github.com/AcademySoftwareFoundation/wg-ci

    • Volunteer(s) to have commit rights? Low volume commitment to review branches.

      • Andrew Grimberg has committer rights already

      • Aloys is volunteering, Andrew to add

    • DCO, Netflify not implemented yet

      • DCO bot should already be in place, DCO bot had issues yesterday (GitHub level issue, was running from an unmaintained project, LF may end up picking up that bot). Should already be turned on for this repo, need to submit a PR to make it required -> today’s notes will serve that.

    • Any additional links we want from the home page?

    • What to do about https://www.aswf.io/community-old/ci-infrastructure/ on the ASWF web site? Should that just redirect to / be hosted in our repo (after Netlifycation)?

      • Aloys: feels out of date, we need to do something about it

  • Updates for VFX Platform 2022 aswf-docker update (Aloys)

    • Not too many updates since last meeting

    • New release of Imath and OpenEXR that need to be picked up

    • Waiting for OpenVDB, will do the last pass once OpenVDB 9 is out, will do last pass when everything is released. OpenVDB confident they will make the end of October release deadline for VFX Platform 2021

    • Conan packages: realizing that won’t have the time, takes 20 minutes - 1h to convert a package from build script to Conan package with tests, too many packages to finish everything. Got up to iMath / OpenEXR, cleaned up the branch and will leave it alone. Will address Larry’s request to have newer clang as a reason to bring bits of Conan into the mainline, try to make it so you can use a script to install any clang you want. Larry: don’t mind if there are extra steps, some of the years had several versions, some only had one. Aloys: may have made mistake, adding clang version was quite painful, makes things more complex than they should. Would like to go back to simpler, one release per year, and use Conan to install more / different things. Larry: because of runner time limits, can’t build a clang from scratch, so has to be binary install. Aloys: want to add Conan in separate folder in base CI image, so you can run a script to download any additional package you need. Will try with clang first, should be achievable before next meeting. Otherwise it will be 2022 to have a complete Conan transition, clang is a good motivation to do it, large package that adds lots of complexity to current images, so a good way to bring value from the work done so far. Will describe how it works at the next meeting / could do a demo. JF: can these script conversions be outsourced to other contributors? Aloys: it can be tricky to ask people to work in a branch they can’t use, so merging the work without changing the current system, just an additional layer of functionality, then it can be documented and others can contribute Conan recipes for additional packages. So will merge the new feature with documentation and presentation to this group, and won’t have to do all the packages myself. Finished IMath / OpenEXR last weekend, was tricky since Imath is a dummy package for OpenEXR 2 (went back to version 2.3 from 2019), lots of CMake bug workarounds required in Conan recipes, seems like a waste of time to focus on old versions, works much better in OpenEXR 3 and modern CMake. Not clear it’s worth making OpenEXR 2.3 work with the new system. JF: we should advertise to the project when Aloys is going to present. Patrick: is Conan the package manager we will promote, or just for CI? Aloys: wouldn’t got as far as that, but will be the one you can use to add more packages to your CI. Would like to make those recipes work on Windows (and eventually macOS), a lot easier on those OSes. Hoping we can contribute more OSes to existing packages. Conan has all the features needed for the aswf-docker project, supports multiple versions, looked at many package managers and seemed to be the only one that had all the features required. Do we promote it as the "ASWF Package Manager?" Good question. Patrick: if the project itself support Conan, for instance OCIO downloads and compiles third party libraries. Aloys: for each package, would make more sense to continue using CMake, some vendors use Conan (Foundry for instance building all their external libraries with Conan), so maybe we can help push Conan as the defacto package manager. But CMake is a known standard. JF: could Foundry be convinced to contribute some of those Conan recipes?

    • Alembic 1.7 vs 1.8 vs Python 3 (see #vfx_reference_platform post by Ashley Whetter)

      • Aloys: don’t build PyAlembic, a bit too painful to do (built only against Python 2.7)

      • Larry: should we request that they bump the Alembic version?

      • Follow up on the vfx platform mailing list

  • Usefulness of "top of tree" containers and build environment variety

    • CentOS Stream / CentOS 8.x / Rocky 8.x

    • Ubuntu / Debian?

    • Easy access to recent toolchains (gcc11): request from Christina Tempelaar-Lietz for OpenEXR, currently using (default GH?) Ubuntu builder

    • Potential combinatorial explosion of configs / containers

    • Larry: depends what we think our mission is. These projects get used outside of strictly VFX industry, and people in the industry that next rev will be "safe", and don’t want to not see incoming issues if we stick to VFX Platform. On OSL, do a “bleeding edge” test, can’t use the docker containers for that, but use the native Ubuntu GitHub Actions runners, which in itself is a useful exercise, different OS, different versions of some packages. Useful to have one build in the matrix as close as possible to “top of tree”, so we could say that projects need to do this, possibly outside the containers. You can trivially install some of the stuff in our containers, but some are VFX specific / have long build times.

    • Patrick: agree that we have to agree if this is part of the mandate, but part of the mandate to provide an easy way to consume our projects, for some people, only building the project is already a major challenge. OCIO gets requests from platforms / compilers which are outside our spec, and can’t build. This prevents them from compiling. So we should thinking about this, it’s a real challenge for C++ libraries. Does it mean we have to support everything / everywhere, of course we can’t, but we should find something to not be purely limited to VFX Platform.

    • JF: Graviton builders now available via AWS CodeBuild. So are ARM builds? Larry: OpenEXR gets issues all the time for subtle issues on ARM builds, includes Linux platforms, and of course Apple Silicon. Not having a good CI test on ARM means we don’t have a good way to catch these issues. At whatever time it becomes easy to include this, OpenEXR will jump on this. Patrick: same for OCIO. JF: try to build aswf-base.

    • Larry: when would GitHub Actions to have Mac M1? Andrew: asked GitHub, no road map for this yet. Having a meeting next week, so no updates for now.

  • From last TAC meeting: some desire for a "standard build matrix" that could be consumed by ASWF projects

    • Andrew: GitHub working on being able to provide org-level workflows that would include matrixes, repo-level level could be moved to organization level, or even GitHUb Action libraries. Larry: skeptical of this, workflow files are not shared, can copy from one to the other, but since dependencies are different, it’s really hard to re-use a workflow file. Andrew: RelEng provides job templates to lots of projects, if a job template is well designed, can have downstream consumers insert some variables and have it "do the right thing" (used on the Jenkins platform, across 10K builds). So it is possible, but the workflow has to be designed well. LF RelEng will start porting Jenkins workflows into this, and then try to focus on other workflows, generic workflows that just need some tweaks.

    • Andrew: what parts of the workflow could be GitHub Actions that could be hosted at the org level, use a series of similar Actions. Jenkins Job Builder creates a bunch of macros, from which job templates are created, made it as composable as possible.

  • Conan / Artifactory vs GitHub Packages: OCIO is interested in GitHub Packages to limit the number of different "vendors" they have to deal with in their CI

    • Andrew: had a lot of those discussions internally and with various projects. Current guidance is that if everything you are doing is in GitHub, you might as well use GitHub resources, it will be faster. But currently GitHub Packages doesn’t do Conan, and their Docker registry is on its third iteration, so is it good enough? Also might not be available outside your organization. But in general want your CI to be as fast as possible, but for security, publish your actual releases to an external registry as well, so there’s at least another place to get them. Patrick: having access to pre-built libraries, from time to time this is a request, some people don’t want to compile OCIO. Andrew: the main caveat of the GitHub Packages registry may be a limitation on the total size of the packages you can store. Artifactory currently has unlimited space, something to consider if you want to keep all official releases "forever", may have to migrate outside of GitHub.

  • ABI stability and conformance

    • Any tools we could help prototype to detect unintended ABI changes?

    • https://lvc.github.io/abi-compliance-checker/

      • Unintended changes

      • Larry: OpenEXR includes inner namespace that includes major and minor version number, but assume we can be API but not ABI compatible from 3.1 to 3.2 (say), so protect consumers with changing namespace. But makes life difficult in another, brainstorming on different approaches, having certain key classes be long term stable, want to make things less painful for something compiled against VFX Platform 2019, instead of having to keep patching old versions of OpenEXR, would like to be able to tell the client to upgrade to OpenEXR 3.2, but that the API entry points will still be there without breaking compatibility with older apps. That way development efforts can be concentrated in current version. But haven't found the right way. If anyone else has gone down that road, happy to hear about it.

      • OpenEXR already doing ABI checking, and when patch releases are done, want to make sure that ABI compatibility isn’t broken. Working on incorporating checkers. Jeff: started using lvc, provides HTML output, but not digestible. Have done a bunch of tests, seems to be quite accurate, finds inadvertent ABI changes. Larry: this is the one OpenEXR is looking at. When you put out the first version, checkin the XML it outputs, then use that XML file as the base to check against. Jeff: first run doesn’t know what to compare against, following runs know how to compare against previous release. Larry: would want to checkin the output of the previous run. Jeff: will regenerate XML differences for old and new every time, done offline. Report will be tagged based on the version, doesn’t block any releases yet, but would be good if it did. Tool needs wrapping to make it useful. Has given great information. Larry: have struggled with DSO versioning, has tripped up OpenEXR a few times. Jeff: moving Imath out of OpenEXR is an example that tripped the tool up. Larry: OpenEXR will write something up once the lessons are well learned.

  • Updates on LF releng code signing infrastructure (Andrew)

    • Do any ASWF projects currently provide signed tarball source releases?

      • Not that we know

    • Andrew: still working on getting it set up, had some issues with making the service fully stable, mostly around access from GitHub. Still under active work, once it is working, there will be a GitHub Action that will do this, some secrets at the org level, and how do you cause a workflow to sign a release. Will be able to sign anything with a detached PGP signature, should also be able to sign with code signing certificates, but haven’t done that yet. Already used to sign Java artifacts, also used for signing GPG commit tags.

Follow Ups

  • Post meeting follow ups on discussion about automatic ChangeLog generation (added to last meeting’s notes):

    • Andrew (via Slack): I'm aware of at least 2 tools that work relatively well for it. The first is using reno which is what LF RE is currently using for our various tooling. It requires people actually adding changelog "slugs" and then you process it all during a CI build step. The other is to use something like Conventional Commits (aka Semantic Commits) and then use something like conventional-changelog-action to produce your changelog directly from your CC messages. LF Release Egineering actually hard enforces the need for CC messages.

    • Jon Wolski (via Slack): My teams use Semantic Release in conjunction with conventional commits, not only to drive changelog generation but also release and artifact versioning.

    • Andrew: my biggest problem with how most folks do CC is that they break rule 3 of what we consider the 7 rules of a great commit message. We actually enforce Capitalized subject lines (rule 3) in the LFRE repositories. We're using the gitlint plugin to pre-commit in the commit-msg hook and modified the default set of accepted types to be a capitalized version of them. Then in our CI, we have a job that actually validates the commit message through that hook. It's a little janky, but it works well enough. I've got pre-commit.ci setup on a personal GitHub repo, but near as I can tell it doesn't actually run that one validation on PRs, otherwise it would actually end up failing it's own automatically raised PRs for bumping plugins. My take on the auto-generators that use CC is that they should have some sort of configuration to allow you to specify your own CC types.