We seem to have been running into upstream errors in binaryen.ml from libbinaryen after releases we should document a proper testing process for this.
Currently, what seems to be smart is:
- Submit a libbinaryen pr with your changes
- Submit a corresponding binaryen.ml pr using an esy resolution
- If it's something major test in the grain repo using another resolution.
- If esy is passing opam is likely to pass however we have seen cases where that isn't the case so it may make sense to release to a fork of the opam-repository and test binaryen.ml with opam set to consume your repo.
As most of the testing happens upstream, this would probably be hard to automate if we wanted to improve a little. Maybe we could have a pre-release workflow that pushes a branch to binaryen.ml with the libbinaryen upgrade and resolutions for testing as a base. We could make it policy that this pr must be passed before we do a libbinaryen release. Though I think more discussion might be needed, as this isn't an ideal workflow, especially for external contributors.
We seem to have been running into upstream errors in
binaryen.mlfrom libbinaryen after releases we should document a proper testing process for this.Currently, what seems to be smart is:
As most of the testing happens upstream, this would probably be hard to automate if we wanted to improve a little. Maybe we could have a pre-release workflow that pushes a branch to binaryen.ml with the libbinaryen upgrade and resolutions for testing as a base. We could make it policy that this pr must be passed before we do a libbinaryen release. Though I think more discussion might be needed, as this isn't an ideal workflow, especially for external contributors.