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

48 lines
1.2 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:
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
# build the application, reporting success if the build completes
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:
image: dyna3:ci
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 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: trunk build
# run the automated tests, reporting success if the tests pass
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:
image: dyna3:ci
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 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: 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
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:
image: dyna3:ci
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 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: cargo run --example irisawa-hexlet
- run: cargo run --example three-spheres
- run: cargo run --example point-on-sphere
- run: cargo run --example kaleidocycle
Reference in a new issue Copy permalink