AcademySoftwareFoundation / AcademySoftwareFoundation/OpenTimelineIO
Add Test pass for build artifacts
- Dominant language
- C++
- Stars
- 2k
- Forks
- 351
- Avg merge
- 1d 12h
- Merged PRs (30d)
- 1
Description
## Feature Request
With github actions producing wheels to deliver to pypi, it would be helpful to have a separate part of our build process to validate those exact artifacts before they can become candidates for pypi delivery.
## Description
At a minimum, smoke tests could be run that did something simple like:
1. Import otio
2. create an example timeline
3. write it to disk
4. read the timeline back into disk
The testing should be run on target platforms called out as supported.
In a perfect world, the full unittest suite would be run against the wheels that are being delivered.
The main objective of this testing should be to catch packaging issues like:
- Not building statically linked to `libopentimelineio` or `libopentime` or missing `.so` files for those in the package (whatever the chosen method of including those functions is)
- Incorrect architecture mismatch in the binary parts of the distribution
- Missing `_otio` module from the package distribution
## Context
Over the course of improving our build system setup, the above listed issues have been hallmark things that pop up when iterating on our somewhat brittle combo of cmake configs and `setup.py`. A sanity check that this class of issues hasn't made it into our artifacts will help catch issues close to where they are introduced and increase our confidence when iterating on the build setup.
Some things to consider:
- In testing, it is important to fail as fast as possible. I think we'd favor relying on the build time unittests a bit more in exchange for faster iteration time on build failures.
- At the time of writing, there are 17 wheels being built. Running tests to cover every one of these may not be worth the effort. It may be best to choose a representative set of platform/python version combos to maximize coverage while minimizing the variant combos of test machines.
Contributor guide
Research direction
Review the GitHub Actions workflow, CMake configuration, and setup.py build process to understand how wheels are produced and which supported platform/Python combinations are available. Add artifact validation that imports otio, creates an example timeline, writes it to disk, and reads it back, with failures detected before PyPI delivery.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cmake, github-actions, python
- Domain
- build-system, ci-cd, testing
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100