Skip to content

ci: Add Maya 2027 to the integ test matrix - #481

Merged
andrew-fenton merged 8 commits into
aws-deadline:mainlinefrom
andrew-fenton:feat/integ-tests-maya-2027
Sep 21, 2026
Merged

andrew-fenton merged 8 commits into
aws-deadline:mainlinefrom
andrew-fenton:feat/integ-tests-maya-2027

Conversation

@andrew-fenton

@andrew-fenton andrew-fenton commented Sep 16, 2026

Copy link
Copy Markdown
Contributor

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.

  1. The adaptor segfaulted on startup. Maya 2027 ships libpython3.13.so under the same soname as the host's Python 3.13, and the mayapy wrapper puts Maya's lib on LD_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.
  2. A hung test could not be diagnosed. The 2027 cell printed nothing for the 22 minutes until the build timed out. run_command captured through pipes, and the adaptor leaves a daemon holding the inherited descriptors, so the read waited for EOF from a process that outlived openjd.
  3. Maya 2027 aborted while writing a PNG. Its libfreetype statically links libpng 1.6.55 and exports the symbols, while Maya's image libraries load the host's libpng16.so.16 (1.6.37). png_* calls bound across the two copies and corrupted the heap.
  4. Windows logs were unreadable. Maya 2027 raises a handled SEH exception importing OpenMaya as SYSTEM, and faulthandler dumped every thread each time — most of the log.
  5. Windows Redshift skipped its install. The probe only looked for the Maya 2025 plugin, so a Redshift install missing a newer version's plugin reported "already installed" and returned — and PluginMaya2027 only lands if the install runs.

What was the solution? (How)

  • Add 2027 to the matrix, with its installers, MtoA 5.6.3, V-Ray 74004, and the openjpeg2/libatomic packages it needs.
  • Run the adaptor through dispatchers that drop only Maya's LD_LIBRARY_PATH entry. The Maya client still goes through mayapy, which re-adds it.
  • Write run_command output 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.
  • Delete Maya's libfreetype.so.6 so ld.so resolves it from /lib64. Both are 2.13.2 and Maya's defines no FT_* symbol the host's lacks. Listed per version in BUNDLED_SONAMES_TO_DROP, so 2025 and 2026 are untouched.
  • Disable pytest's faulthandler on Windows. Maya still reports its own fatal errors and the adaptor logs its own.
  • Check one Redshift plugin per requested Maya version on Windows, and derive the component list and registration loop from those versions rather than hardcoding them.

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 only libclang, and 2027 dropped libfreetype.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 — and test_redshift_scene_adaptor passed 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 touches pipeline/, hatch.toml and test/integ/helpers/.

@github-actions github-actions Bot added the waiting-on-maintainers Waiting on the maintainers to review. label Sep 16, 2026
Comment thread pipeline/setup-runner.py
Comment thread pipeline/setup-runner.py Outdated
Comment thread hatch.toml
Comment thread pipeline/setup-runner.py
Comment thread pipeline/setup-runner.py
Comment thread pipeline/setup-runner.py
Comment thread pipeline/setup-runner.py
Comment thread pipeline/setup-runner.py
Comment thread hatch.toml
Comment thread pipeline/setup-runner.py
Comment thread pipeline/setup-runner.py
Comment thread test/integ/helpers/test_runners.py
Comment thread test/integ/helpers/test_runners.py
Comment thread pipeline/setup-runner.py
@andrew-fenton
andrew-fenton force-pushed the feat/integ-tests-maya-2027 branch from 0330281 to 3edf257 Compare September 17, 2026 19:10
Comment thread pipeline/setup-runner.py
Comment thread pipeline/setup-runner.py
Comment thread pipeline/run-integ-tests.py Outdated
Comment thread pipeline/setup-runner.py
Comment thread test/integ/helpers/test_runners.py
Comment thread pipeline/setup-runner.py
Comment thread pipeline/run-integ-tests.py Outdated
Comment thread pipeline/setup-runner.py
Comment thread pipeline/setup-runner.py
Comment thread pipeline/setup-runner.py
Comment thread pipeline/setup-runner.py Outdated
Comment thread test/integ/helpers/test_runners.py
@andrew-fenton
andrew-fenton force-pushed the feat/integ-tests-maya-2027 branch from a8cd2a9 to 707fb99 Compare September 17, 2026 20:31
Comment thread pipeline/setup-runner.py Outdated
@andrew-fenton
andrew-fenton requested a review from a team as a code owner September 17, 2026 23:46
jairaws
jairaws previously approved these changes Sep 18, 2026
TanoVip123
TanoVip123 previously approved these changes Sep 18, 2026
Comment thread pipeline/run-integ-tests.py Outdated
Comment thread pipeline/run-integ-tests.py
@andrew-fenton
andrew-fenton dismissed stale reviews from TanoVip123 and jairaws via e4dd7f8 September 18, 2026 22:11
Comment thread pipeline/setup-runner.py Fixed
Comment thread pipeline/setup-runner.py Outdated
Comment thread pipeline/setup-runner.py
@andrew-fenton
andrew-fenton force-pushed the feat/integ-tests-maya-2027 branch from e4dd7f8 to 195f02c Compare September 18, 2026 22:57
Comment thread pipeline/setup-runner.py
Comment thread pipeline/setup-runner.py
Comment thread pipeline/setup-runner.py
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
andrew-fenton force-pushed the feat/integ-tests-maya-2027 branch from 195f02c to 988fb36 Compare September 18, 2026 23:31
Comment thread pipeline/setup-runner.py
Comment thread pipeline/setup-runner.py
TanoVip123
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>
Comment thread pipeline/setup-runner.py
@andrew-fenton
andrew-fenton merged commit 281c04c into aws-deadline:mainline Sep 21, 2026
30 of 31 checks passed
@andrew-fenton
andrew-fenton deleted the feat/integ-tests-maya-2027 branch September 21, 2026 22:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

waiting-on-maintainers Waiting on the maintainers to review.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants