StudioInfinity/dyna3
2
0
Fork 1
Code Issues 44 Pull requests Projects 2 Releases 2 Wiki Activity Actions
dyna3/.forgejo/workflows/continuous-integration.yaml

31 lines
925 B
YAML
Raw Normal View History

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
# build the application, reporting success if there are no errors or warnings
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
build:
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:
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:
- uses: https://code.forgejo.org/actions/checkout@v4
Run CI on a stock image, installing Trunk by hand Instead of building a custom CI image with Trunk pre-installed, let's try running CI on a stock image, installing Trunk from a binary on every workflow run.
2025-03-27 20:46:02 -07:00
- uses: ./.forgejo/setup-trunk
Fail continuous integration on warnings
2025-03-08 11:11:01 -08:00
- run: RUSTFLAGS='-D warnings' trunk build
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
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
# each example target with `test = true` and `harness = false` in Cargo.toml
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:
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:
- uses: https://code.forgejo.org/actions/checkout@v4
Run the examples as tests
2025-03-28 00:36:38 -07:00
- run: RUSTFLAGS='-D warnings' cargo test
Reference in a new issue Copy permalink