ci: Add Maya 2027 to the integ test matrix - #481
Merged
andrew-fenton merged 8 commits intoSep 21, 2026
Merged
andrew-fenton merged 8 commits into
andrew-fenton merged 8 commits into
Conversation
andrew-fenton
force-pushed
the
feat/integ-tests-maya-2027
branch
from
September 17, 2026 19:10
0330281 to
3edf257
Compare
andrew-fenton
force-pushed
the
feat/integ-tests-maya-2027
branch
from
September 17, 2026 20:31
a8cd2a9 to
707fb99
Compare
jairaws
previously approved these changes
Sep 18, 2026
TanoVip123
previously approved these changes
Sep 18, 2026
andrew-fenton
dismissed stale reviews from TanoVip123 and jairaws
via
September 18, 2026 22:11
e4dd7f8
andrew-fenton
force-pushed
the
feat/integ-tests-maya-2027
branch
from
September 18, 2026 22:57
e4dd7f8 to
195f02c
Compare
Maya 2027 bundles Python 3.13, and needs openjpeg2, libatomic and libpng beyond 2026's set of system libraries. The renderer builds that support it changed shape, so their installs need more than a version entry: - MtoA 5.6.3 ships its payload as package.tgz rather than package.zip, which the installer step rejected outright. - V-Ray 7.40.04 silently unpacks nothing given the equals-joined -unpackInstall=<dir> form that worked for 7.2, and no longer ships vray/bin/vray. Invoke it as the MayaVray Conda recipes do and verify vrayformaya.so, the plugin they patchelf, which both builds ship. - Redshift ships one installer for every Maya version, so 2025 and 2026 move to 2026.8.1 as well. Require a redshift4maya directory per requested version rather than trusting .installed alone: reserved capacity carries a marker from 2026.3.1, which predates Maya 2027 and has no plugin for it, and would otherwise skip the reinstall. Both renderer installs now fail rather than warning and marking an incomplete install done. Signed-off-by: Andrew Fenton <afento@amazon.com>
All four adaptor tests failed on the Maya 2027 cell, each exiting -11 (SIGSEGV) entering the Maya environment, before the child produced any output. The 2025 and 2026 cells passed 10 of 10, and 2027's six submitter tests passed, since they run inside mayapy and never start the adaptor. MayaAdaptor resolves to the hatch env's console script, so the adaptor runs on the host Python, which is 3.13 on this runner. Maya 2027 ships libpython3.13.so under the same soname, and the mayapy wrapper puts Maya's lib dir on LD_LIBRARY_PATH, which the adaptor inherits from pytest, so it loaded Maya's copy. Maya 2025 and 2026 bundle Python 3.11, which is why only 2027 crashed. Dispatch through scripts that drop Maya's entry and keep the rest, so the renderer libraries stay resolvable. The Maya client is launched via mayapy, whose wrapper re-adds Maya's own entry. Signed-off-by: Andrew Fenton <afento@amazon.com>
The Maya 2027 cell hung with no output: pytest collected 10 items and printed nothing for the 22 minutes until the build timed out. Two things could hold it there, and the log could not distinguish them, because run_command captured through pipes and printed only after returning. Write to temp files instead. The adaptor backgrounds a daemon that inherits our stdout and stderr, so a pipe read waits for EOF from the surviving grandchild even once openjd has exited. Verified locally: a child that exits immediately while leaving a background process holding the inherited descriptors blocks capture_output for as long as that process lives, and returns at once when writing to files. Add a 120s timeout so a genuinely stuck run fails with whatever output it produced, rather than waiting on the onEnter action's 87000s template timeout. flaky retries each adaptor test three times, so this caps the four of them at 24 minutes inside a 60 minute build. Set PYTHONUNBUFFERED and PYTHONFAULTHANDLER on Linux: the daemon is a subprocess and does not get pytest's faulthandler, so a SIGSEGV discarded its unflushed stdout. Not on Windows, where they make the Maya client dump the ERROR_NO_TOKEN exceptions it otherwise handles. Signed-off-by: Andrew Fenton <afento@amazon.com>
Maya 2027's libfreetype.so.6 statically links libpng 1.6.55 and exports its 369 png_* symbols globally, declaring no libpng in DT_NEEDED. Maya's image libraries load the host's libpng16.so.16 (1.6.37) instead, so png_* calls bind across the two copies and abort: libpng reads garbage dimensions from a mismatched struct, reports "Invalid IHDR data", then double frees. test_minimal_scene_adaptor hit this on the 2027 cell, where Maya aborted at 9s with signal 6 and the test timed out at 120s waiting on the surviving adaptor daemon. The same scene renders on a service-managed fleet, whose conda package replaces Maya's freetype with the system one, which has no png exports. Both freetypes are 2.13.2 and Maya's defines no FT_* symbol the host's lacks, so deleting it lets ld.so resolve libfreetype.so.6 from /lib64. Maya 2025 and 2026 link libpng dynamically and are left alone. Signed-off-by: Andrew Fenton <afento@amazon.com>
Maya 2027 raises an SEH exception importing OpenMaya under the SYSTEM account the CodeBuild agent runs as (0x800703f0, ERROR_NO_TOKEN). Maya handles it and all ten tests pass, but faulthandler dumps every thread on each occurrence, which made up most of the 2245 log events and buried the run's actual output. Maya still reports its own fatal errors and the adaptor still logs its own, so the failure modes we diagnose from these logs stay visible. Signed-off-by: Andrew Fenton <afento@amazon.com>
The per-version wrapper appended the inherited value with `:${VAR:-}`, which
emits the separator even when the variable is unset. The adaptor dispatchers
added earlier in this branch run the adaptor with LD_LIBRARY_PATH unset, so the
Maya client they launch got `<maya>/lib:` — and an empty element makes ld.so
resolve every needed library relative to the working directory first. Verified:
a trailing colon produces 76 relative lookup attempts, without it zero.
Use `${VAR:+:$VAR}` so the separator only appears when there is something to
append, for all five path variables the wrapper sets.
Also contain _drop_bundled_sonames to lib_dir, so a SONAME that resolves
outside it is reported rather than deleted, and use a named constant for the
adaptor dispatch directory instead of repeating the literal.
Signed-off-by: Andrew Fenton <afento@amazon.com>
The probe only looked for the Maya 2025 plugin, so a Redshift install missing a newer version's plugin reported "already installed" and returned. That matters now that 2027 is in the matrix, since PluginMaya2027 only lands if the install runs. Check one plugin per requested version, and derive the component list and the registration loop from those versions instead of hardcoding them. Also drop the PYTHONUNBUFFERED and PYTHONFAULTHANDLER block: its Windows caveat overlapped confusingly with the faulthandler flag added for the pytest process. Signed-off-by: Andrew Fenton <afento@amazon.com>
andrew-fenton
force-pushed
the
feat/integ-tests-maya-2027
branch
from
September 18, 2026 23:31
195f02c to
988fb36
Compare
TanoVip123
previously approved these changes
Sep 18, 2026
The dispatchers are hard to justify without the process tree: the tests run under mayapy, so every process below inherits Maya's lib directory, and only the adaptor is not Maya. Show that tree, name the collision that follows, and say why the filter is selective rather than unsetting the variable. Drops the previous claim that the filter preserves renderer libraries. Nothing puts renderer paths on LD_LIBRARY_PATH, and the adaptor would not load them anyway; the Maya client gets them through MAYA_MODULE_PATH and MAYA_PLUG_IN_PATH. Signed-off-by: Andrew Fenton <afento@amazon.com>
andrew-fenton
commented
Sep 21, 2026
kenyrish-amazon
approved these changes
Sep 21, 2026
TanoVip123
approved these changes
Sep 21, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What was the problem/requirement? (What/Why)
Maya 2027 was not covered by the integ tests. Adding it surfaced four defects, three of them Linux-only.
libpython3.13.sounder the same soname as the host's Python 3.13, and themayapywrapper puts Maya'slibonLD_LIBRARY_PATH, which the adaptor inherits. It loaded Maya's copy and died. 2025 and 2026 bundle Python 3.11, so only 2027 was affected.run_commandcaptured through pipes, and the adaptor leaves a daemon holding the inherited descriptors, so the read waited for EOF from a process that outlivedopenjd.libfreetypestatically links libpng 1.6.55 and exports the symbols, while Maya's image libraries load the host'slibpng16.so.16(1.6.37).png_*calls bound across the two copies and corrupted the heap.PluginMaya2027only lands if the install runs.What was the solution? (How)
openjpeg2/libatomicpackages it needs.LD_LIBRARY_PATHentry. The Maya client still goes throughmayapy, which re-adds it.run_commandoutput to temp files instead of pipes, and bound it at 120s so a stuck run fails with its output rather than at the template's 87000s timeout.libfreetype.so.6sold.soresolves it from/lib64. Both are 2.13.2 and Maya's defines noFT_*symbol the host's lacks. Listed per version inBUNDLED_SONAMES_TO_DROP, so 2025 and 2026 are untouched.Redshift keeps taking every requested Maya version: one install serves all of them, and a host may carry a marker from an older Redshift with no
redshift4maya/2027.What is the impact of this change?
Maya 2027 is tested on Linux and Windows. No behaviour change for 2025 or 2026 on Linux.
How was this change tested?
Local:
hatch run style,typing(77 files),test(222 tests), plus black 25 and 26.Integ run 35276606937, both platforms green, 10 passed per cell on 2025, 2026 and 2027. The install path was exercised from scratch in run 35271320399, which reinstalled all three versions: 2025 linked
libssl/libcrypto/libclang, 2026 onlylibclang, and 2027 droppedlibfreetype.so.6. Windows went from 9 SEH dumps to 0. Run 35400440423 exercised the Windows Redshift install for the first time — it had always been skipped by the 2025-only probe — andtest_redshift_scene_adaptorpassed on all three cells, so the per-version installs do not remove each other's plugins.Integ test result
Run 35276606937 — Linux and Windows green.
Installer test result
N/A —
installer/not modified.Did you run the "Job Bundle Output Tests"? If not, why not? If so, paste the test results here.
N/A — no changes under
src/. This PR only touchespipeline/,hatch.tomlandtest/integ/helpers/.