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

50 lines
1.5 KiB
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:
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
image: rust:1.85-bookworm
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
# without 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
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:
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
image: rust:1.85-bookworm
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
Fail continuous integration on warnings
2025-03-08 11:11:01 -08:00
- run: RUSTFLAGS='-D warnings' cargo test
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
# run the Cargo examples, as described here:
#
# Karol Kuczmarski. "Add examples to your Rust libraries"
# http://xion.io/post/code/rust-examples.html
#
Fail continuous integration on warnings
2025-03-08 11:11:01 -08:00
# report success if the examples build and run without 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
run-examples:
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:
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
image: rust:1.85-bookworm
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
Fail continuous integration on warnings
2025-03-08 11:11:01 -08:00
- 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
Reference in a new issue Copy permalink