Currently, I use a CI server to test and build a plugin for Rhino and upload it to our server.
To distribute the latest version of the plugin without needing to edit the food4rhino page every time, I use a URL rewrite to redirect
mysite.com/download/plugin.rhi to whatever the latest version is i.e.
mysite.com/download/plugin_126.96.36.199.rhi. This technique works well, but I’d like to integrate a yak release into the project (and that way have food4rhino reference the yak package rather than the server rewrite).
From what I can tell there are two challenges here:
Get the CLI: The yak CLI is bundled with Rhino. Is there a way I can retrieve the latest version of the CLI on the server without Rhino? We use RhinoCommon from NuGet.
Authorization: Yak requires a Rhino Account login. Is there a way I can:
- Generate a longer lived access token/api key (that ideally has reduced scopes), so I can store it in the secrets for the CI server
- Provide an access token to the Yak CLI via a command
There’s a lot of appeal for us in having a non-customized server instance and installing all dependencies as part of the CI.
Has anyone got a cloud-hosted CI server creating builds for Yak?
Hey! I think we have most of the pieces in place to do this…
- A standalone version of the Yak CLI can be downloaded from https://files.mcneel.com/yak/tools/latest/yak.exe.
- To get a suitable auth token, run
yak login --ci locally. This will generate a non-expiring auth token and print it to the command line. The token is scoped to the “yak” client, so it can’t be used for anything else related to your Rhino Account. In your CI environment store the token as a secret and set it as the value of the
YAK_TOKEN environment variable so that yak.exe can used it.
- I recommend not using
yak spec in the CI build. Instead run it locally and add the manifest.yml to version control. In manifest.yml, you can use a placeholder for the version field, i.e.
version=$version and the build command will populate this from the Rhino plug-in.
A couple of examples using GitHub Actions…
It’s possible to sync packages published to the public server with F4R. It may need a little manual intervention from the F4R team to get this working with an existing F4R “app”.
Perfect! Thanks for the tips, took a total of 5 minutes to set up.
(My search-fu definitely failed me this time - sorry!)
Would the best practice here to be to only offer the package via Yak? Will we end up with conflicts if people mix usage of the .rhi and yak package for different versions?
One other thing that would be useful would be to specify the platform in the manifest.
Not difficult to work around though; for posterity I used this to rename mac/win packages appropriately:
$YAK_FILENAME = (dir *.yak).Name
$YAK_UPLOAD = $YAK_FILENAME -replace "-any.yak","-mac.yak"
Rename-Item -Path $YAK_FILENAME -NewName $YAK_UPLOAD
..\yak push $YAK_UPLOAD
Yeah, it can cause problems because Rhino will try to load the same plug-in from two different places which can lead to a conflict. If your plug-in supports Rhino 6, then you may want to keep the .rhi around for those users. I think you can have both a package manager download and a file-based download on your F4R page – I’d get in touch with them to check the best way to go (#food4rhino or email@example.com).
The build command has a
--platform argument that might help here!
..\yak build --platform win
..\yak build --platform mac
I’ll probably just keep both available for now and advise people to use one or the other based on preference.