Fix CI GitHub action

[acolwell]

Thanks for submitting a pull request! Please provide enough information so that others can review your pull request. Additionally, make sure you've done all of these things:

• [x] I've followed the contributing guidelines to the best of my understanding
• [x] I've read and understood the contributing guidelines
• [x] I've formatted my code according to Natron's code style
• [x] I've searched the pull requests tracker to ensure that this PR is not a duplicate

PR Description

What type of PR is this? (Check one of the boxes below)

• [ ] Bug fix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [x] Improvement (non-breaking change which does not add functionality nor fixes a bug but improves Natron in some way)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)
• [ ] My change requires a change to the documentation
  • [ ] I have updated the documentation accordingly

What does this pull request do?

• Fixed Linux so it builds again.
• Added Windows build.
• Made unit tests run on both platforms. These rely on prebuilt, self-contained, openfx-io plugin binaries so that this project's CI action does not have to worry about how to build the plugins or what their dependencies might be.

Have you tested your changes (if applicable)? If so, how?

Yes. I've run this updated CI action in my fork (https://github.com/acolwell/Natron/actions/runs/5481256325). It should also run when this pull request is submitted.

Futher details of this pull request

This change depends on https://github.com/NatronGitHub/openfx-io/pull/35. Without that patch the Windows build can hang during shutdown and make the CI process unreliable. Currently this action is running against self-contained plugin binaries that contain this pull request. Once https://github.com/NatronGitHub/openfx-io/pull/35 and https://github.com/NatronGitHub/openfx-io/pull/36 are landed, I can change this CI action to point to binaries generated by the official openfx-io CI action.

[devernay]

LGTM! Why not put the pre-built binaries in a repo in the natrongithub org? (Could be a repo dedicated to ci artifacts)

[acolwell]

LGTM! Why not put the pre-built binaries in a repo in the natrongithub org? (Could be a repo dedicated to ci artifacts)

I could do that if you prefer. I was just using the release/tag mechanism out of convenience and it seemed like we really didn't need the binaries themselves to be under version control. I was envisioning that the tags/releases used for CI binaries would just be periodically updated and we didn't really need a historical record of previous binaries. I was planning on creating the necessary releases/tags in the official Natron & openfx-io repositories once these were approved (right now they point to releases in my fork).

I do not feel strongly about this either way. Just trying to explain my thinking. :)

[devernay]

LGTM! Why not put the pre-built binaries in a repo in the natrongithub org? (Could be a repo dedicated to ci artifacts)

I could do that if you prefer. I was just using the release/tag mechanism out of convenience and it seemed like we really didn't need the binaries themselves to be under version control. I was envisioning that the tags/releases used for CI binaries would just be periodically updated and we didn't really need a historical record of previous binaries. I was planning on creating the necessary releases/tags in the official Natron & openfx-io repositories once these were approved (right now they point to releases in my fork).

I do not feel strongly about this either way. Just trying to explain my thinking. :)

Are these pre -built binaries the artifacts of some other GitHub action in openfx-io? If yes, maybe there's a standard mechanism to fetch the latest artifacts? I agree that probably don't need to be versioned

[acolwell]

LGTM! Why not put the pre-built binaries in a repo in the natrongithub org? (Could be a repo dedicated to ci artifacts)

I could do that if you prefer. I was just using the release/tag mechanism out of convenience and it seemed like we really didn't need the binaries themselves to be under version control. I was envisioning that the tags/releases used for CI binaries would just be periodically updated and we didn't really need a historical record of previous binaries. I was planning on creating the necessary releases/tags in the official Natron & openfx-io repositories once these were approved (right now they point to releases in my fork). I do not feel strongly about this either way. Just trying to explain my thinking. :)

Are these pre -built binaries the artifacts of some other GitHub action in openfx-io? If yes, maybe there's a standard mechanism to fetch the latest artifacts? I agree that probably don't need to be versioned

So the pre-built binaries for the plugins used by the Natron unit tests are the self-contained artifacts from the openfx-io CI. Eventually, I believe we could have the plugin CI action update the testing release/tag when code is merged to the stable branch. I was wary about doing that initially because I didn't want to cause flakiness or weird interactions between the two CI actions. My initial plan was to periodically manually update the testing release tags & binaries with artifacts generated by the last CI run for the stable branch. After we've had some successful runs for a while, I can follow-up with a fully automated solution. The same would go for the Window pacman repo that is built with the build_pacman_repo action and used to build the openfx-io plugins on Windows.

How does that sound?