Reading through some of the documentation has been good but WAY over my head. I think at one point I was reading about how FAT32 works and the miracles you all did to make hardware, offline and the PXT editor work (which is awesome but way beyond what I can comprehend).
What I’m looking at right now is the details of how the github workflows work and generally how the simulator runs.
Does the simulator run just javascript code or does it run the built UF2 thing?
Looking at the workflow file (release), it appears to build several different versions of the code and then smush them all together. Then outputs those as a release. However the github pages just simply serves up the index.html page which looks like it depends on binary.js (is that the JS version of the game for the simulator?)
I think the intention is that when you make a github release you would then get the binary versions of the project put into the release but also then maybe have the built version that’s served up by the github pages be updated? I just don’t see anything in the workflow file that would seem to do that.
Example project:
The latest code just has “this is version 2”
But the github pages version is the older one:
Also note that the deprecated actions/upload-release-asset@v1.0.1 seems to be throwing an error, so maybe that’s the problem?
tl;dr; I’m willing to work out the workflow file to build a new version of the game every time I make a github release but I’m not sure about the overall strategy with the UF2 files vs “is it just running javascript” in the browser simulator.
Ok after a few hours of debugging (debugging github actions is never fun) I think I understand now how this works.
Web = uses binary.js (so yes, the simulator is running JS not UF2)
Currently the github action DOES build the web version as it’s called debug/binary.js and lives in the built folder. However that file is lost in the current actions right as the next build procedure creates a UF2 file and then copies it to a new location (the built folder is cleaned every time).
I worked out the kinks and updated a lot of packages and now I have a github pages page that will rebuild the UF2 and binary.js file. And it only does this when you create a release in github. With this you can point something like itch to your github pages site and know that each time you make a release in github it’ll be updated automatically (users may need to force-refresh since there’s a lot of caching that happens on the client side).
Here’s my current makecode release action:
A few things to note:
I had to modify the loader.js becuase it was reading a meta string that’s placed on top of the binary.js file. When I was having the actions run pxt build it was NOT putting that meta at the top, so I just have the loader manually put that information in!
I’ve manually added the query params to remove the simulator chrome (in loader.js), in the future I’d like to make this more responsive in that if it’s viewed on a phone the chrome would show, otherwise (desktop/console/arcade) it hides.
I had to change the build deployment option in github pages to “Github Actions” since the actions are now creating the github page (otherwise it’ll run an automatic set of actions for the jekkyl pages)
I dislike having global npm installations, I’ve run into too many situations where the developer and build server have different versions and it causes headaches. So for this (and likely future projects of mine) I’m installing pxt in the project itself as a dev dependency and then in my PATH i have ./node_modules/.bin/ added (or I just manually type all of that in). The action in this case modifies the path so the commands pxt build still look good and build properly, but now they are using the same version that the developer did.
Please let me know if I’m completely off base. Also maybe this could be a solid update for the arcade github template?