Restructure plugin to include a baseline demo #168
Conversation
BastiaanOlij
force-pushed
the
baseline_300_alpha
branch
23 times, most recently
from
5314fca to
4be6b2f
Compare
BastiaanOlij
force-pushed
the
baseline_300_alpha
branch
from
4be6b2f to
233a505
Compare
|
Ok, this is pretty much ready to be merged. On a PR it will now do a build of both the plugin by itself, and the full demo including embedding the OpenXR library. When tagging it prepares a full release with those two entities. Note that when you examine the zip files they have a root directory, this may seem a bit duplicitous but it is required to publish these zip files on the asset library. |
| rm -rf demo/godot-xr-tools/.github | ||
| - name: Add OpenXR Plugin | ||
| run: | | ||
| wget --header "Authorization: token ${{ secrets.GITHUB_TOKEN }}" "https://github.com/GodotVR/godot_openxr/releases/download/1.3.0/godot-openxr.zip" |
There was a problem hiding this comment.
For now we'll need to hardcode the version of the OpenXR plugin we embed in our demo asset.
There was a problem hiding this comment.
I think this works fine for now. I was thinking it could be a build-job variable accessed by the yaml; however I can't find how to set variables through the web; and even if it worked, we might want to have different versions specified for different branches - something embedding in the yaml is capable of achieving.
It does mean we have to update the yaml when the repo wants to jump forwards a rev; but that seems a small price to pay for having the explicit control in branches.
This is our first step to restructuring our repo. This just introduces the base files for our demo. I'll likely merge this as is so I can start working on the CI that creates our deliverables, while Malcolm starts applying a lot of the refactoring.