I have been trying to use Act to run my pluginās action to build locally, but I am running into an error where the container does not have NodeJS in its Path.
Is there a reason why you have forked the Rack toolchain to build the container (other than just being faster to make changes to it)?
Any thoughts on how I might fix this NodeJS issue?
The issue suggests something like:
- name: Hack container for local development
if: ${{ env.ACT }}
run: echo /home/runner/externals/node20/bin >> $GITHUB_PATH
then later suggests this will cause bugs, and possibly a custom env for the docker image like:
FROM blah...
ENV PATH "/home/runner/externals/node20/bin:$PATH"
but this is currently beyond my level of understanding
edit: ah I am assuming the above code would live in the Dockerfile, but not sure what blah... would be
2nd edit: hmm, well answered part of the question for myself, building the docker image from the rack repo fails, but building the docker image from your fork worksā¦
With the release announcement of Rack 2.6.0, is there anything that needs to be updated in these build scripts? The one item mentioned in the announcement that might cause issues is:
Donāt combine SDK packages for Mac-x64 and Mac-arm64.
Today Iām going to start exploring what happens when I target my Sapphire plugin to the 2.6.0 SDK, and see if I can tell whether the existing build steps still work in GitHub Actions. I wonder if anyone else has already gone down that road and has anything interesting to share?
OK, I just pushed a change to my own Sapphire pluginās documentation, which triggered running all my GitHub Actions unit tests as an expected side effect. It appears to still be using the 2.5.2 SDK:
--2024-11-22 20:35:06-- https://vcvrack.com/downloads/Rack-SDK-latest-mac-x64%2barm64.zip
Resolving vcvrack.com (vcvrack.com)... 107.191.126.116
Connecting to vcvrack.com (vcvrack.com)|107.191.126.116|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: Rack-SDK-2.5.2-mac-x64+arm64.zip [following]
--2024-11-22 20:35:07-- https://vcvrack.com/downloads/Rack-SDK-2.5.2-mac-x64+arm64.zip
Reusing existing connection to vcvrack.com:443.
HTTP request sent, awaiting response... 200 OK
Length: 11511814 (11M) [application/zip]
Saving to: āRack-SDK.zipā
If Iām reading this right, when you ask the vcvrack.com server for the latest SDK, it redirects you into downloading the 2.5.2 zip file. I believe this is because they are still calling Rack 2.6.0 āpre-releaseā, so it is not the official latest version yet.
So this got me thinking, what if I edit the GitHub Actions yml file to target the specific SDK 2.6.0. I did this and it fails:
--2024-11-22 20:49:00-- https://vcvrack.com/downloads/Rack-SDK-2.6.0-mac-x64%2barm64.zip
Resolving vcvrack.com (vcvrack.com)... 107.191.126.116
Connecting to vcvrack.com (vcvrack.com)|107.191.126.116|:443... connected.
HTTP request sent, awaiting response... 404 Not Found
2024-11-22 20:49:00 ERROR 404: Not Found.
The root cause is apparent when you look at the https://vcvrack.com/downloads/. As announced in the changelog, the MAC SDKs are now provided as separate files for arm64 and x64:
Thanks @qno for putting this together and keeping it current, and for everyone else who has been keeping things going. Iāve been using a LInux machine to build for Lin & Win, and a Mac for X86, but havenāt been able to get Mac ARM build working; this does the trick and is much easier.
In an effort to give back, if anyone is like me and constantly tinkering with readme files or other docs in the same repo and wasnāt already savvy with GitHub Actions, I updated my build script to only run the action on pushes to source code-related files (json, res, src) using āpath filtersā.
I replaced this:
on: [push, pull_request]
with:
on:
push:
paths:
- '**.json'
- 'src/**'
- 'res/**'
Now it only triggers on pushes to plugin.json or any source/resource file, and I can tweak docs and doc images without all the plugins building. Obviously you can edit for your needs/files.
Update: VCV Rack has released SDK 2.6.0. I noticed this by my GitHub Actions workflow getting a 404 error trying to download Mac SDKs. As expected, changes are required to your GitHub Actions workflows in 2.6.0. In my workflow yml file I also replaced ālatestā with ā2.6.0ā because it looks like they no longer have a file that includes the name ālatestā.
Here are my example changes for other developers who might benefit from this.
Just an FYI that the latest officially released version of Rack is still 2.5.2. v2.6.0 was a preview that never got released, because of problems I think.
All the previews are, that doesnāt mean it was released, because of e.g. problems. So I would personally caution against using SDK-2.6.0 for anything that should be released.
I would like some clarity on this point if possible, the changelog posted by Don would suggest the version is considered ready, especially considering the commit changes from in development to 2024-11-20
My assumption was that the announcement was just forgotten about (but I concede that I might be making an ass of myself).
As a dev it would be nice if I were easily able to tell if a build on the downloads page is preview or not, or if there are known issues with the current in development next version, to have somewhere that could be documented.
I agree that Andrew should be a whole lot more stringent and clear about version numbers, previews, development blogs, changelogs and what is actually considered a release and what is not. Hereās my take:
Of course, Andrew could have simply āforgottenā to release v2.6.0 but I doubt it, that hasnāt happened before, but what has happened many times before, is a preview version that was never released, because of problems people reported that needed to be fixed first, and I do remember people complaining about problems with 2.6.0.
In a really disciplined world you do it like this:
You have one or more development/testing channels/logs/blogs/pages, where you produce builds for people to try out and report back. They will be called things like product-3.9.1-alpha1, product-3.9.1-beta3, etc. When you think itās ready you produce product-3.9.1-rc1 (rc == Release Candidate), which is the ālast chance to find show-stoppersā build.
When you think itās good enough you release product-3.9.1, which is ideally identical to product-3.9.1-rc1 except for the version number. This is the released version and you proclaim that loudly in your release channel/twitter/blog/whatever.