Academy Software Foundation - Project Requirements Office Hours - September 25, 2024

Join the meeting at https://zoom-lfx.platform.linuxfoundation.org/meeting/97880950229?password=81d2940e-c055-43b9-9b5a-6cd7d7090feb

Attendees

  • Jean-Francois Panisset - WG CI
  • John Mertic - LF
  • Yarille Ortiz - LF
  • Gary Oberburnner - OpenFX
  • Eric Reinecke - OTIO
  • Larry Gritz - OIIO / OSL
  • Stephen Mackenzie - Rez

Meeting Minutes

  • John: timing for this call was brought up. Running into issue that there’s no good time slot, this time conflicts with USD meetings (off cadence from TAC), but also avoids some other conflicts. Or should we have a secondary timeslot that we would flip between the two? Larry: sounds reasonable, as long as they are recorded. Gary: I’m flexible so good with me.
    • John: if we picked a second time, what would that be? Stephen: best answered by people who couldn’t attend today. John: main conflict with USD? JF: same with WG CI. Stephen: timeband between noon and 4PM Easter is crowded. Larry: any earlier than this cuts out Australia / New Zealand. John: do we look at a later time? Would work better later? But then can be an issue for Europe.
    • John: Tuesday could be a bit more open.
    • JF: is there enough overlap with CI WG to want to merge? Stephen: does LFX tools have heat map of best attended meeting? Overlapping with another meeting may not be that big of an issue if the other meeting has fewer attendees? John: we have data on attendees, USD WG has 217 people who registered.
    • We could try for the DPEL TSC meeting on Tuesdays at one.
    • JF: if every project moves to adopted phase, are we done?
    • John: will put out poll on the tech leads channel of sticking to current slot vs Tuesday offset from DPEL TSC.
  • Signing releases
    • MaterialX did it, and moved on their graduation
    • Other project leads, any feedback?
    • Gary: giving it a try now, instructions are clear. Mostly stuck on how to test it without generating lots of extra releases. Larry: “release and hope it works”? Gary: yes, I could do that. But would like to see it run end to end.
    • John: have to ‘test in production’? Gary: workflow based on tags and releases. Eric: haven’t worked through this yet, hopefully next week. In general any of the work we do are happening in normal CI builds, release just promotes artifacts to PyPI. Not sure what the expense is to cryptographically sign every build we do. John: intention is not every build, but every release. Eric: but if every build is signed, then every build is a release candidate. When we create a release, it just grabs the artifacts from the build and promotes those. Gary: using release-sign.yml which does something different. Eric: makes sense to only sign the release, doesn’t really matter either way? Gary: it does matter to testing though, don’t want a “weird” release sitting up GitHub that you have to delete / move tags around.
    • John: this adds an artifact to the existing release? You can try putting this in place. Eric: can you manually trigger an action? Gary: yes, I added the manual trigger, but then it doesn’t have a tag. I can probably debug that, hardwire an existing tag. But was wondering what everybody else is doing.
    • John: can you unpublish releases? Gary: yes. John: could you unpublish and republish an old release? Gary: yes, that’s an interesting idea, I’ll try it.
    • John: based on Eric’s process, this would sit on the end of the process? Eric: yes, we are creating a release in GitHub. Would merge this to our workflow of “stuff that happens on a release”. We have one that is the same trigger on release publish. We need to make this happen before the PyPI publish since the signature has to show on PyPI. Gary: as long as you don’t have to re-download the artifacts. I don’t have anything that happens “on publish”. Eric: will look how this will work with PyPI. We’re using a PyPA GitHub action, you may be able to pass it the signing artifacts.
    • Eric: looks like PyPI Publish can generate its own attestation objects. So may not need this whole workflow at all? But we’ll want to sign the source artifacts. Makes dealing with PyPI specifics easier. John: PyPI steering packages towards doing this. Eric: would be good if this was done more extensively.
    • John: looks like we have OpenFX in progress, and OTIO soon.
    • Larry: haven’t started yet, it’s on my list, looking to have the time. Missed the first office hours with Cary.
    • Stephen: same story for Rez. We do our OpenSSF in big batches, Jean-Christophe has done a lot. We marked Cary’s ticket as a duplicate since we already had a ticket.
    • John: we have people who now have experience so can help answer questions. Maybe use the #technical-leads channel to ask for help.
    • Stephen: for reproducibility of GitHub Actions, there are solutions out there for ways to run a local GitHub Actions container as a local host that you connect to your project, there are different ways to debug GitHub Actions “live”. Could be something we should be aware of across projects, how you can dig in and debug stuff without having to make a release. JF: could be a topic for WG-CI, or a Wiki article. Gary: you want to be able to run workflows with simulated triggers. Stephen: there’s another approach where the GitHub Actions can install a tool that you can attach to remotely. There is likely a well known approach. ACT
    • Eric: tool to debug actions you are developing
    • Eric: there should be a way to have a dry run of a release. But so many things in action are built to have side effects.
    • Gary: if CI WG had recommendations / walkthroughs for GHA debugging / local runs, that would be very helpful.
  • Dependabot
    • John: are projects using Dependabot to keep actions up to date?
    • Stephen: those updates can be annoying
    • John: you can group them and reduce frequency?
    • Stephen: yes we do that. Dependabot at first wasn’t helpful, there’s a major update in something we relied on, and Dependabot was complaining about something we couldn’t update.
    • JF: Stephen helped aswf-docker to move past logjam, but it’s now asking for a new version of Python Black which another dependency doesn’t support yet.
    • Eric: you can tell it to ignore certain dependencies for a while.
    • Stephen: Rez vendors several of its dependencies, so Dependabot doesn’t know about these
    • Larry: other projects have trouble incorporating Dependabot paradigm since they are trying to be able to build in different environments they need to build in, like studio environments. There isn’t a single nailed down environment, including older environments. Haven’t turned it on for my projects, since not sure how to deal with the noise it would generate.
    • John: main requirement is to have a mechanism to stay on top of dependencies, Dependabot is a mechanism for that, but doesn’t work as well for C/C++. Larry: what does it mean to “stay on top of it?” John: “project must monitor or periodically check their external dependencies”. Larry: there may not be a single version of external dependencies, you may have to support building against a range of versions, even known insecure ones. Eric: perhaps the intent was if you are generating binary artifacts you are downloading? Larry: not generating binaries for now, but will be generating Python wheels. For that purpose, we can make sure that for the binaries we build, we use “acceptable” versions. Larry: we feel obligated to run CI against wide range of versions. If / when we produce binaries, those will have to be built against “known good” dependencies.
    • John: if someone were to pull your code and pull dependencies themselves, they should be able to get the “good ones”? Larry: both of the projects I run test not only against VFX Platform, but also latest versions, and sometimes from main / nightly / top of tree to guard against surprises. Stephen: sometimes a lot of Dependabot updating is to keep 2 things under control: does your CI system have vulnerabilities and could supply chain attack people downstream of you, and are the things that your project works with will create downstream supply chain attacks by projects that use yours. Most ASWF projects aren’t getting used in that context? It may be irrelevant for some projects.
    • John: SBOMs can also help mitigate, attestation of dependencies and known vulnerabilities. The point is to pay attention to dependencies! End users can make decisions for their own use cases.
    • Eric: the OpenSSF lets you enter a description string / qualifier, so projects can document that way that they support builds against older versions? John: true, but the idea is to attest that we pay attention to dependencies. Doesn’t mean you can’t test against older / vulnerable versions.
  • Sounds like signed releases is still the outstanding TODO, setting up StepSecurity may be a good objective, in particular pining actions to specific SHA-1 hashes