Set up continuous integration in Forgejo #75
|
|
@ -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
|
||||
|
glen marked this conversation as resolved
Outdated
|
||||
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
|
||||
|
|
@ -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
OK, so if I understand this is the setting that makes (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
(A) Right now, my main use case for (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
|
||||
|
|
|
|||
Why isn't this path
../.forgejo/setup-trunk? That would seem to be the relative path from the working-directory to the action. I mean, I am not suggesting the file is incorrect; I am just saying the notation is unclear, and my particular concern is that when we (presumably sometime soon) remove the app-proto layer of the hierarchy, that this workflow file be reasonably resilient to that.I think the label
defaults.run.working-directorysets the default only forrunsteps, like in GitHub Actions.How is the working directory for a uses step determined then? Should that be made explicit in this file somehow?
In meeting, we concluded that Aaron will push a commit that adds some mild commentary he is comfortable with elucidating how the current directory state is evolving during this workflow.
In the
setup-trunkaction, you added the comment: "Assume we remain in the top-level directory of the checkout." It seems to me, though, that it doesn't really matter wheresetup-trunkruns: Trunk will be added to the path regardless. What were you thinking might go wrong ifsetup-trunkran somewhere else? Or was this comment just meant to indicate that, for the sake of organization,setup-trunkshould be run from the top-level directory of the checkout?The GitHub Actions documentation is clearer about how the path to a local action is specified. This is consistent with the behavior I've seen in Forgejo Actions.
What I meant was: it was our intention that trunk be installed in a directory ci-bin created at the top level of the project hierarchy. The script as written only accomplishes that intention if it in fact is the case that post the
run: rustup...action it remains that case that the current directory is the top-level directory. [Sorry about the delay in posting this, apparently I forgot to hit the Reply button last night when I wrote it, and only discovered that omission today when I started closing all of my numerous open browser windows.]Ah, and now we have crossed to some extent. When you push clarifying comments as you see fit for the location of the uses action and/or what the checkout does to the current directory (I think those are the points we discussed, feel free to adjust the comment I put in to the setup-trunk action so that my intended meaning is clearer. Thanks!
Got it! It turns out that the
setup-trunkaction doesn't actually do that, because I was wrong during the meeting about how location control works in actions. The workflow comes with a workspace directory, which is the default place to run commands and place files that are shared between steps. This is mentioned in the Forgejo Actions glossary:As of commit
efb2d39, thesetup-trunkaction createsci-binwithin the workspace directory, even if we tell thecheckoutaction to check the repository out to somewhere else.I've made a second commit (
440b1df) that adjusts your comment and makes the location used insetup-trunkmore explicit. Feel free to revert or modify it if you'd like.@Vectornaut wrote in #75 (comment):
Agreed, but because it installs ci-bin as as a subdirectory of the workspace, and it checks out the repository so that its top-level directory is exactly the workspace, the ci-bin directory does end up at the top level of the checkout (as verified by an explicit
lsstep I temporarily put in the workflow). As a consequence, I clarified the comments on checkout to note exactly where the top-level directory of the repo ends up, and I leftci-binin.gitignorebecause in CI, that's where it ends up, so if somehow ever (A) the CI steps ran directly in the host [hard to imagine] or (B) we had a CI action that created a commit [slightly more plausible, even if unlikely], the ci-bin directory would be ignored. With those changes, I am resolving this conversation, and merging the PR. Thanks for all of your efforts on this!