# Objective
- Run examples in WASM in CI
- Fix#4817
## Solution
- on feature `bevy_ci_testing`
- add an extra log message before exiting
- when building for wasm, read CI config file at compile time
- add a simple [playwright](https://playwright.dev) test script that opens the browser then waits for the success log, and takes a screenshot
- add a CI job that runs the playwright test for Chromium and Firefox on one example (lighting) and save the screenshots
- Firefox screenshot is good (with some clusters visible)
- Chromium screenshot is gray, I don't know why but it's logging `GPU stall due to ReadPixels`
- Webkit is not enabled for now, to revisit once https://bugs.webkit.org/show_bug.cgi?id=234926 is fixed or worked around
- the CI job only runs on bors validation
example run: https://github.com/mockersf/bevy/actions/runs/2361673465. The screenshots can be downloaded
# Objective
- ~~Running examples on Linux in CI timeout~~Linux is back!
- But hey we can run examples on windows too!
## Solution
- Run examples on windows daily
- I also added a 30 minutes timeout so that when it explodes, it doesn't explodes in 6 hours (the default timeout)
- And simplified the linux examples by not requiring a custom feature set
# Objective
This fails constantly and causes more pain than it is worth.
## Solution
Remove dead link checks.
Alternative to #4837, which is more granular but ironically still fails to build. I'm in favor of the nuclear option.
Fixes#4575
# Objective
- Original objective was to add doc build warning check to the ci local execution
- I somewhat deviated and changed other things...
## Solution
`cargo run -p ci` can now take more parameters:
* `format` - cargo fmt
* `clippy` - clippy
* `compile-fail` - bevy_ecs_compile_fail_tests tests
* `test` - tests but not doc tests and do not build examples
* `doc-test` - doc tests
* `doc-check` - doc build and warnings
* `bench-check` - check that benches build
* `example-check` - check that examples build
* `lints` - group - run lints and format and clippy
* `doc` - group - run doc-test and doc-check
* `compile` - group - run compile-fail and bench-check and example-check
* not providing a parameter will run everything
Ci is using those when possible:
* `build` jobs now don't run doc tests and don't build examples. it makes this job faster, but doc tests and examples are not built for each architecture target
* `ci` job doesn't run the `compile-fail` part but only format and clippy, taking less time
* `check-benches` becomes `check-compiles` and runs the `compile` tasks. It takes longer. I also fixed how it was using cache
* `check-doc` job is now independent and also run the doc tests, so it takes longer. I commented out the deadlinks check as it takes 2.5 minutes (to install) and doesn't work
# Objective
Fixes#1529
Run bevy_ecs in miri
## Solution
- Don't set thread names when running in miri rust-lang/miri/issues/1717
- Update `event-listener` to `2.5.2` as previous versions have UB that is detected by miri: [event-listener commit](1fa31c553e)
- Ignore memory leaks when running in miri as they are impossible to track down rust-lang/miri/issues/1481
- Make `table_add_remove_many` test less "many" because miri is really quite slow :)
- Make CI run `RUSTFLAGS="-Zrandomize-layout" MIRIFLAGS="-Zmiri-ignore-leaks -Zmiri-tag-raw-pointers -Zmiri-disable-isolation" cargo +nightly miri test -p bevy_ecs`
# Objective
- Nightly checks where disabled because of a bug in Rust
- Dependency checks are failing because of a new duplicate
## Solution
- Now that https://github.com/rust-lang/rust/pull/92175 has been merged, re-enable nightly checks
- Add the new duplicate dependency to the known list
- Removed `Inflector` dependency as it's not used anymore
Co-authored-by: François <8672791+mockersf@users.noreply.github.com>
# Objective
- Fixes#2674
- Check that benches build
## Solution
- Adds a job that runs `cargo check --benches`
Co-authored-by: Carter Anderson <mcanders1@gmail.com>
# Objective
- #2551 revamped our CI setup which included running clippy and rustfmt in another Job.
- This new Job wasn't added to the bors.toml, which means that PRs would be accepted that didn't run them.
## Solution
- Add the "ci" job to the bors.toml
# Objective
- Related to #2514 - not sure if it's a proper fix long term
- CI was complaining Error: Path `"/usr/local/lib/android/sdk/ndk-bundle/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android31-clang"` was not found
- A lot of questions started popping up 10 days ago about ["android build tools 31 corrupted"](https://www.google.com/search?q=android+build+tools+31+corrupted)
- https://stackoverflow.com/questions/68387270/android-studio-error-installed-build-tools-revision-31-0-0-is-corrupted
- Uninstalling `"build-tools;31.0.0"` doesn't seem to work, as it removes other components even though `"build-tools;30.0.3"` are available
## Solution
- Uninstalling `"platforms;android-31"` seems to do the trick and `cargo-apk` stops trying to target `...31`
Android is not my thing, this solution was found with a lot of trials and errors. I am not sure how long term it is, I don't know the release schedule of android build tools, or if we need to target this 31 thing. I just wanted to stop all those failed ci everywhere...
# Objective
- CI is failing because of an android issue
- This is blocking bors
## Solution
- Bors can ignore android failures
- Keep android job in CI to check its status
I'm not android enough to debug this one, this is a temp fix until someone knows how to fix it or it get fixed by itself with updates?
# Objective
Currently we can sometimes allow PRs by people who haven't agreed to the relicense to get merged into main.
E.g. https://github.com/bevyengine/bevy/pull/2445
## Solution
This adds a check to ensure that this doesn't happen, by ensuring that bors doesn't relicense said PRs.
As a bonus, it also adds config to automatically label new PRs as needing checking, to ensure that we do the verification until we merge the new license.
Adds an GitHub Action to check all local (non http://, https:// ) links in all Markdown files of the repository for liveness.
Fails if a file is not found.
# Goal
This should help maintaining the quality of the documentation.
# Impact
Takes ~24 seconds currently and found 3 dead links (pull requests already created).
# Dependent PRs
* #2064
* #2065
* #2066
# Info
See [markdown-link-check](https://github.com/marketplace/actions/markdown-link-check).
# Example output
```
FILE: ./docs/profiling.md
1 links checked.
FILE: ./docs/plugins_guidelines.md
37 links checked.
FILE: ./docs/linters.md
[✖] ../.github/linters/markdown-lint.yml → Status: 400 [Error: ENOENT: no such file or directory, access '/github/workspace/.github/linters/markdown-lint.yml'] {
errno: -2,
code: 'ENOENT',
syscall: 'access',
path: '/github/workspace/.github/linters/markdown-lint.yml'
}
```
# Improvements
* Can also be used to check external links, but fails because of:
* Too many requests (429) responses:
```
FILE: ./CHANGELOG.md
[✖] https://github.com/bevyengine/bevy/pull/1762 → Status: 429
```
* crates.io links respond 404
```
FILE: ./README.md
[✖] https://crates.io/crates/bevy → Status: 404
```
* makes CI fails on cargo doc warnings
* adds this check in bors
doc warnings are listed here: https://doc.rust-lang.org/rustdoc/lints.html
Currently the warnings emitted are:
* broken_intra_doc_links
* private_intra_doc_links
* invalid_codeblock_attributes
I have run the VSCode Extension [markdownlint](https://marketplace.visualstudio.com/items?itemName=DavidAnson.vscode-markdownlint) on all Markdown Files in the Repo.
The provided Rules are documented here: https://github.com/DavidAnson/markdownlint/blob/v0.23.1/doc/Rules.md
Rules I didn't follow/fix:
* MD024/no-duplicate-heading
* Changelog: Here Heading will always repeat.
* Examples Readme: Platform-specific documentation should be symmetrical.
* MD025/single-title
* MD026/no-trailing-punctuation
* Caused by the ! in "Hello, World!".
* MD033/no-inline-html
* The plugins_guidlines file does need HTML, so the shown badges aren't downscaled too much.
* ~~MD036/no-emphasis-as-heading:~~
* ~~This Warning only Appears in the Github Issue Templates and can be ignored.~~
* ~~MD041/first-line-heading~~
* ~~Only appears in the Readme for the AlienCake example Assets, which is unimportant.~~
---
I also sorted the Examples in the Readme and Cargo.toml in this order/Priority:
* Topic/Folder
* Introductionary Examples
* Alphabetical Order
The explanation for each case, where it isn't Alphabetical :
* Diagnostics
* log_diagnostics: The usage of inbuild Diagnostics is more important than creating your own.
* ECS (Entity Component System)
* ecs_guide: The guide should be read, before diving into other Features.
* Reflection
* reflection: Basic Explanation should be read, before more advanced Topics.
* WASM Examples
* hello_wasm: It's "Hello, World!".
