Add touch-bar plugin

[PatrickKocken]

I implemented Adam's feedback on my previous pull request. I added Github Actions workflows in my repositories to improve the transparency of the native library.

In the repository with the native library code I created a workflow that builds the native library, creates a release for the repository and uploads the native library as an asset to the newly created release.

In the plugin repository I created a workflow that removes removes the old native library from the repository, downloads the release of the native library repository, commits the native library and pushes the commit to a new branch. This workflow is dispatched on every new release of the native library in the other repository.

Plugin repository Workflows Workflow file

Native library repository Workflows Workflow file

Github Actions automated pull requests

If you have any questions about this plugin feel free to ask them in this conversation

---

Runelite Touch Bar

A plugin that adds Macbook Pro Touch Bar support for Runelite.

Screenshots

Config

Make sure the keybinds in Runescape and in the Touch Bar Plugin config match.

Native Library

This plugin uses a Dynamic Link Library in order to use the Macbook's Touch Bar. The source code of the native library can be found here.

[runelite-github-app[bot]]

New plugin touch-bar: https://github.com/PatrickKocken/runelite-touch-bar/tree/ceae900f1f2c18b8084cf31d6e05d27e320faa02

[Adam-]

FYI - we prefer if you just update your existing PR instead of closing and opening a new one, since it loses all context of the previous discussions. And is also spammy.

Any reason why this runs on a self-hosted runner and not one of the github ones? I think all you would have to do is 1) use the github runner so we know the runner isn't backdoored and then 2) have the action upload the artifact to the workflow like eg

    - uses: actions/upload-artifact@v3
      with:
        name: linux-x64
        path: src/main/native/fips-deploy/packr/linux-make-release/packr

3. ensure the build is reproducible, so that the hash of the file in the plugin matches this one. Then that should be possible for us to review.

[abextm]

also 4) have the runner print the sha512 of the artifact immediately after it is built

[PatrickKocken]

Hello Adam and Abex,

Thank you for your feedback. The reason I initially went for a self hosted runner is because I had some trouble signing the native library in Xcode and forgot to change it back to one of the Github's runners.

Instead of creating a release of the native library in the native library repository I switched to actions artifacts. I created separate artifacts for the native library and the checksum of the native library.

In the plugin repository I trigger an action that downloads the artifacts, compares the checksum and creates a pull request with the latest native library and its checksum.

I hope the usage of native library is more transparent now.

[PatrickKocken]

Hello @Adam- and @abextm

If there are thing still unclear regarding the transparency of the native library please let me know so I can fix this.

[Adam-]

Hello @Adam- and @abextm

If there are thing still unclear regarding the transparency of the native library please let me know so I can fix this.

Is the code signing on actions actually required for this? Eg. if I wanted to just build it myself instead to avoid doubt. Since it is loaded into RL which is already running I am not sure if that is required.