A set of Github Actions for working with 3DS applications and the rust3ds
toolchain.
It's recommended to use the test-runner
crate from ctru-rs
when working with these actions, in order to get useful test output on failures.
setup
: action for setting up the Rust 3DS toolchain in workflowsrun-tests
: action for running test executables with Citra in workflows
This example shows the default value for each of the inputs.
jobs:
test:
runs-on: ubuntu-latest
container:
image: devkitpro/devkitarm
volumes:
# This is required so the test action can `docker run` the runner:
- '/var/run/docker.sock:/var/run/docker.sock'
steps:
- name: Checkout branch
uses: actions/checkout@v4
- name: Setup Rust3DS toolchain
uses: rust3ds/actions/setup@v1
with:
# Optionally use a more specific nightly toolchain here if desired
toolchain: nightly
- name: Build and run tests
uses: rust3ds/actions/run-tests@v1
with:
# Optionally add arguments to pass to `cargo 3ds test`
args: ''
# Optionally set the name of the built test-runner docker image
runner-image: test-runner-3ds
# Optionally change to a given directory before running tests. Note
# that this should use the environment variable ${GITHUB_WORKSPACE}
# rather than ${{ github.workspace }} to avoid the issue described in
# https://github.com/actions/runner/issues/2058
working-directory: ${GITHUB_WORKSPACE}
See ci.yml
to see a full lint and test workflow
using these actions (including uploading output artifacts from the tests).
- Since the custom test runner runs as part of
cargo test
, it won't be able to find a3dsx
that hasn't built yet.cargo-3ds
doesn't build3dsx
executables until after the cargo command it runs internally, so this means that tests can't depend on any features of the3dsx
(like embedded romFS). A workaround for this is to simply build the tests as a separate step before running them, after which the runner will be able to find the3dsx
.