build artifacts in source control #15
Description
It appears that interface/schemata/device.json and docs/openapi.yaml are never touched by humans and are only ever generated by build-openapi.sh. Small point, the name build-openapi doesn't imply to me that it will also touch device.json, but maybe I'm just not familiar enough with the project.
Currently when checked out on main (not at head, but at the top commit not labeled "wip"), when build-openapi.sh is run, changes are made to device.json and openapi.yaml. Which leave the submodule showing changes. Not the biggest deal, but when it comes time to update the submodule, will conflict with pulling. Obviously you can just discard first, its just a little bit messy.
Normally one doesn't commit generated files in source control, because it is easy to forget to run the build script before doing a commit and push. I suggest removing the files from control, and .gitignoring them. Folks that need the files can build them. For the openapi.yaml, I understand that we want to be able to point swagger at https://raw.githubusercontent.com/SMPTE/st2138-a/refs/heads/main/docs/openapi.yaml. I suggest instead creating releases in github, and uploading the file as an artifact. You'll still be able to access it with a url, just slightly different. Something like https://github.com/smpte/st2138-a/releases/download/v1.0.0/openapi.yaml We can even make a workflow to automate this.
If it is important that either of the files are committed in source tracking, I suggest a workflow to build and commit the files on push, so that they are at least guaranteed to always be up-to-date, but this isn't ideal, because then main will get out of sync.... maybe a workflow for develop then....