StudioInfinity/dyna3
2
0
Fork 1
Code Issues 44 Pull requests Projects 2 Releases 2 Wiki Activity Actions

Set up continuous integration in Forgejo #75

Merged
glen merged 23 commits from Vectornaut/dyna3:forgejo-ci into main 2025-04-02 20:31:42 +00:00
Conversation 64 Commits 23 Files changed 7 +23 -22
2 changed files with 23 additions and 22 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files
Showing only changes of commit 0a9d234557 - Show all commits

25
.forgejo/workflows/continuous-integration.yaml
View file

@ -17,7 +17,8 @@ jobs:
- run: RUSTFLAGS='-D warnings' trunk build
# run the automated tests, reporting success if the tests pass and were built
# without warnings
# without warnings. the examples are run as tests, because we've configured
# each example target with `test = true` and `harness = false` in Cargo.toml
test:
runs-on: docker
container:
@ -27,24 +28,4 @@ jobs:
working-directory: app-proto
steps:
- uses: https://code.forgejo.org/actions/checkout@v4
- run: RUSTFLAGS='-D warnings' cargo test
# run the Cargo examples, as described here:
#
# Karol Kuczmarski. "Add examples to your Rust libraries"
# http://xion.io/post/code/rust-examples.html
#
# report success if the examples build and run without errors or warnings
run-examples:
runs-on: docker
container:
image: cimg/rust:1.85-node
defaults:
run:
working-directory: app-proto
steps:
- uses: https://code.forgejo.org/actions/checkout@v4
- run: RUSTFLAGS='-D warnings' cargo run --example irisawa-hexlet
- run: RUSTFLAGS='-D warnings' cargo run --example three-spheres
- run: RUSTFLAGS='-D warnings' cargo run --example point-on-sphere
- run: RUSTFLAGS='-D warnings' cargo run --example kaleidocycle
- run: RUSTFLAGS='-D warnings' cargo test

20
app-proto/Cargo.toml
View file

@ -50,3 +50,23 @@ wasm-bindgen-test = "0.3.34"
[profile.release]
opt-level = "s" # optimize for small code size
debug = true # include debug symbols
[[example]]
name = "irisawa-hexlet"
test = true
harness = false
glen marked this conversation as resolved
glen commented 2025-03-29 00:27:56 +00:00
Review
Copy link

OK, so if I understand this is the setting that makes cargo test also run e.g. the irisawa-hexlet example. Given that:

(A) Is the run-examples shell script now redundant, and should it be removed in this PR?

(B) Given that the parameters for all four examples are exactly the same, is there any way for this manifest file to just say that test should be true and harness false for everything in the examples directory? That seems likely to remain the case for the foreseeable future, and would have the advantage that we could add another example test by just creating a file in the examples directory.

OK, so if I understand this is the setting that makes `cargo test` also run e.g. the `irisawa-hexlet` example. Given that: (A) Is the run-examples shell script now redundant, and should it be removed in this PR? (B) Given that the parameters for all four examples are exactly the same, is there any way for this manifest file to just say that test should be true and harness false for everything in the examples directory? That seems likely to remain the case for the foreseeable future, and would have the advantage that we could add another example test by just creating a file in the examples directory.
Vectornaut commented 2025-03-29 05:42:27 +00:00
Review
Copy link

(A) Right now, my main use case for run-examples is to get the printed output of the examples in a known order with no extra output mixed in. When we address #77, I plan to turn this into a script for updating the recorded output that we're testing against. Since cargo test doesn't really seem designed for this, I'd recommend keeping run-examples for now.

(B) When we address #77, we're probably going to bring the example test runs back into the test harness, where they'll be called in a different way. Thus, streamlining the current call methods may not be useful in the long term.

(A) Right now, my main use case for `run-examples` is to get the printed output of the examples in a known order with no extra output mixed in. When we address #77, I plan to turn this into a script for updating the recorded output that we're testing against. Since `cargo test` doesn't really seem designed for this, I'd recommend keeping `run-examples` for now. (B) When we address #77, we're probably going to bring the example test runs back into the test harness, where they'll be called in a different way. Thus, streamlining the current call methods may not be useful in the long term.
[[example]]
name = "kaleidocycle"
test = true
harness = false
[[example]]
name = "point-on-sphere"
test = true
harness = false
[[example]]
name = "three-spheres"
test = true
harness = false