dyna3/.forgejo/workflows/continuous-integration.yaml

on:
  pull_request:
  push:
    branches: [main]
jobs:
  # run the automated tests, reporting success if the tests pass and were built
  # without warnings. the examples are run as tests, because we've configured
  # each example target with `test = true` and `harness = false` in Cargo.toml.
  # Trunk build failures caused by problems outside the Rust source code, like
  # missing assets, should be caught by `trunk_build_test`
  test:
    runs-on: docker
    container:
      image: cimg/rust:1.85-node
    defaults:
      run:
        # set the default working directory for each `run` step, relative to the
        # workspace directory. this default only affects `run` steps (and if we
        # tried to set the `working-directory` label for any other kind of step,
        # it wouldn't be recognized anyway)
        working-directory: app-proto
    steps:
      # Check out the repository so that its top-level directory is the
      # workspace directory (action variable `github.workspace`, environment
      # variable `$GITHUB_WORKSPACE`):
      - uses: https://code.forgejo.org/actions/checkout@v4
      
      - uses: ./.forgejo/setup-trunk
      - run: RUSTFLAGS='-D warnings' cargo test
Prototype a continuous integration workflow This workflow is too spendthrift for deployment: every job sets up Rust, and the `build` job also installs Trunk, which takes even more resources. The workflow serves well, however, as a proof of concept. Introducing a syntax error into `src/main.rs` causes the `build` and `test` jobs to fail, but allows `run-examples` to succeed. Similarly, introducing a syntax error into `examples/point-on-sphere.rs` causes `run-examples` to fail, but allows the other jobs to succeed. 2025-03-06 22:24:52 -08:00			`on:`
			`pull_request:`
			`push:`
			`branches: [main]`
			`jobs:`
Fail continuous integration on warnings 2025-03-08 11:11:01 -08:00			`# run the automated tests, reporting success if the tests pass and were built`
Run the examples as tests 2025-03-28 00:36:38 -07:00			`# without warnings. the examples are run as tests, because we've configured`
Do the Trunk build check as an end-to-end test This consolidates our whole CI workflow into `cargo test`. 2025-03-28 12:30:02 -07:00			# each example target with `test = true` and `harness = false` in Cargo.toml.
			`# Trunk build failures caused by problems outside the Rust source code, like`
			# missing assets, should be caught by `trunk_build_test`
Prototype a continuous integration workflow This workflow is too spendthrift for deployment: every job sets up Rust, and the `build` job also installs Trunk, which takes even more resources. The workflow serves well, however, as a proof of concept. Introducing a syntax error into `src/main.rs` causes the `build` and `test` jobs to fail, but allows `run-examples` to succeed. Similarly, introducing a syntax error into `examples/point-on-sphere.rs` causes `run-examples` to fail, but allows the other jobs to succeed. 2025-03-06 22:24:52 -08:00			`test:`
			`runs-on: docker`
Run continuous integration on a custom image Write a Dockerfile that describes a Debian image with our build environment set up in it. Write a script that builds and tags the custom image. Set the continuous integration workflow to run on the custom image, pulled from Docker's local image store. Running the examples on the custom image takes the same steps as running them on a development machine, so we no longer gain anything from factoring out the `cargo run --example` steps. That means we can get rid of the `run-examples` action. Since the build environment is now set up ahead of time, we can get rid of the `setup-rust` action too. 2025-03-07 01:25:30 -08:00			`container:`
Switch to CircleCI's Rust + Node container image This should make the `checkout` work on the runner host. 2025-03-27 22:19:54 -07:00			`image: cimg/rust:1.85-node`
Run continuous integration on a custom image Write a Dockerfile that describes a Debian image with our build environment set up in it. Write a script that builds and tags the custom image. Set the continuous integration workflow to run on the custom image, pulled from Docker's local image store. Running the examples on the custom image takes the same steps as running them on a development machine, so we no longer gain anything from factoring out the `cargo run --example` steps. That means we can get rid of the `run-examples` action. Since the build environment is now set up ahead of time, we can get rid of the `setup-rust` action too. 2025-03-07 01:25:30 -08:00			`defaults:`
			`run:`
Clarify where stuff happens in the CI workflow 2025-04-02 12:06:01 -07:00			# set the default working directory for each `run` step, relative to the
			# workspace directory. this default only affects `run` steps (and if we
			# tried to set the `working-directory` label for any other kind of step,
			`# it wouldn't be recognized anyway)`
Run continuous integration on a custom image Write a Dockerfile that describes a Debian image with our build environment set up in it. Write a script that builds and tags the custom image. Set the continuous integration workflow to run on the custom image, pulled from Docker's local image store. Running the examples on the custom image takes the same steps as running them on a development machine, so we no longer gain anything from factoring out the `cargo run --example` steps. That means we can get rid of the `run-examples` action. Since the build environment is now set up ahead of time, we can get rid of the `setup-rust` action too. 2025-03-07 01:25:30 -08:00			`working-directory: app-proto`
Prototype a continuous integration workflow This workflow is too spendthrift for deployment: every job sets up Rust, and the `build` job also installs Trunk, which takes even more resources. The workflow serves well, however, as a proof of concept. Introducing a syntax error into `src/main.rs` causes the `build` and `test` jobs to fail, but allows `run-examples` to succeed. Similarly, introducing a syntax error into `examples/point-on-sphere.rs` causes `run-examples` to fail, but allows the other jobs to succeed. 2025-03-06 22:24:52 -08:00			`steps:`
doc: Clarify the destination of checkout, remove investigative steps 2025-04-02 13:20:34 -07:00			`# Check out the repository so that its top-level directory is the`
			# workspace directory (action variable `github.workspace`, environment
			# variable `$GITHUB_WORKSPACE`):
Prototype a continuous integration workflow This workflow is too spendthrift for deployment: every job sets up Rust, and the `build` job also installs Trunk, which takes even more resources. The workflow serves well, however, as a proof of concept. Introducing a syntax error into `src/main.rs` causes the `build` and `test` jobs to fail, but allows `run-examples` to succeed. Similarly, introducing a syntax error into `examples/point-on-sphere.rs` causes `run-examples` to fail, but allows the other jobs to succeed. 2025-03-06 22:24:52 -08:00			`- uses: https://code.forgejo.org/actions/checkout@v4`
Clarify where stuff happens in the CI workflow 2025-04-02 12:06:01 -07:00
Do the Trunk build check as an end-to-end test This consolidates our whole CI workflow into `cargo test`. 2025-03-28 12:30:02 -07:00			`- uses: ./.forgejo/setup-trunk`
Run the examples as tests 2025-03-28 00:36:38 -07:00			`- run: RUSTFLAGS='-D warnings' cargo test`