Add outputs for the archive and checksum files

[matiaskorhonen]

Adds outputs from the action for the archive file name(s) and checksum file name(s).

This should enable using those in subsequent workflow steps, such as Artefact Attestations.

For example:

permissions:
  id-token: write
  contents: read
  attestations: write

#
# (the rest of the steps)
#

- uses: taiki-e/upload-rust-binary-action@v1
  id: upload-rust-binary-action
  with:
    dry-run: true
    bin: test-crate
    target: ${{ matrix.target }}
    build-tool: ${{ matrix.build_tool }}
    checksum: sha256,sha512,sha1,md5
    tar: all
    zip: all
    manifest-path: test-crate/Cargo.toml
    codesign: '-'

- name: Generate artifact attestation
  uses: actions/attest-build-provenance@v1
  with:
    subject-path: ${{ steps.upload-rust-binary-action.outputs.zip }}

# or

- name: Generate artifact attestation
  uses: actions/attest-build-provenance@v1
  with:
    subject-path: "${{ steps.upload-rust-binary-action.outputs.archive }}.*"

Hopefully I got most of the details right as I'm familiar with building GitHub Actions for the marketplace…

[aolsenjazz]

Hey there! Windows is a sad story.

As of today there exists only one MIDI framework for Windows that supports virtual ports. As this framework requires license negotiation with the creator, I'm not interested in using it.

Waiting and hoping for an open source/MIT license alternative to pop up for the time being. Will leave this ticket open because it is an issue I'd like to have fixed.

[antt0n]

Hello,

I don't know how you use your virtual ports, but the JZZ (MIT) lib allows you to do that. But it works a little bit differently.

[aolsenjazz]

Thanks for sending this! I must've missed it in my search. Will look into and see what can be done with it.

[aolsenjazz]

Circling back. It seems like this is not possible using the JZZ collection of libraries:

This JZZ issue seems to indicate that native virtual ports are opened via a different library, midi-test. The readme states that it also doesn't support Windows.

If you've found a different way or read these things differently, please let me know!

[aolsenjazz]

Looks like Microsoft might be building native support for MIDI devices: https://github.com/microsoft/MIDI

Virtual MIDI ports are listed as a near-term goal, and the specific issue was marked as in-progress in Oct

[cy4njk]

Hey there! I'm in no way knowledgeable regarding Windows MIDI support, but the mentioned issue seems to be marked as completed. Does that bring us closer to SuperController on Windows?

[aolsenjazz]

Hey, sorry for the delay here. Unfortunately, it doesn't really move us substantively closer.

What we're really waiting for w.r.t. Windows is the rollout of the new MIDI 2.0 API. I was given a timeline of hopefully Q1-Q2 by one of the engineers for the Windows MIDI 2.0 public rollout. That said, we'll also need support to be added to a couple underlying libraries (rtmidi, @julusian/midi) following that.

Hopefully support for our additional underlying libraries will be incrementally added using the developer preview Windows APIs so that support will be added soon after release of MIDI 2.0, but no guarantee.