# Objective
Rust's nightly builds semi-regularly break us (or our dependencies). This creates churn and angst when we're just trying to get our jobs done.
We do still want nightly builds for a variety of reasons:
* cargo-udeps requires nightly and likely always will.
* Helps us catch rust nightly bugs quickly. We're "good citizens" if we regularly report regressions.
* Lets us prepare for "actual expected breakage" ahead of stable releases so we avoid breaking main users.
## Solution
* This pr parameterizes the nightly toolchain, making it an easy one-liner to pin our builds to a specific nightly, when required.
* Put nightly jobs to check wasm and nightly on their own matrix. I also removed tests on nightly linux, just build check
* alternative to https://github.com/bevyengine/bevy/pull/5329
Co-authored-by: Carter Anderson <mcanders1@gmail.com>
# Objective
- Reduce confusion as the example opens a window and isn't truly "headless"
- Fixes https://github.com/bevyengine/bevy/issues/5260.
## Solution
- Rename the example and add to the docs that the window is expected.
This gives users a hint to use the GitHub "Discussions" for questions about bevy, instead of filing an issue.
## Objective
> Users sometimes file unhelpful issues when asking questions about how to use Bevy.
We should provide a link to the Discussion board in the list of "new Issue" options. This hopefully allows users to better find this option and reduces the number of question-issues.
- fixes#5150
## Solution
- add a small config.yml that configures the link
Looks like this (currently live on my local fork https://github.com/themasch/bevy/issues/new/choose):
![grafik](https://user-images.githubusercontent.com/170171/176940564-cd3a4ad1-731b-4417-95c2-3b5285120c88.png)
---
## Open questsions
- I am unsure about the wording.
# Objective
When `miri` runs in our build system to detect unsoundness, its output can be very unhelpful, as the tests are all run in parallel.
## Solution
Add a comment documenting the extremely obvious 10/10 command used by @BoxyUwU in #4959.
I've stuck this in the CI file, as it seems like the most obvious place to check when frustrated. I didn't put it in CONTRIBUTING.md because this is an eldritch abomination and will never be useful to new contributors.
# Objective
Fixes#5155. This *should* work now that the semver breaking dependency of the CI crate got yanked, but we'll see what CI has to say about it.
The first leak:
```rust
#[test]
fn blob_vec_drop_empty_capacity() {
let item_layout = Layout:🆕:<Foo>();
let drop = drop_ptr::<Foo>;
let _ = unsafe { BlobVec::new(item_layout, Some(drop), 0) };
}
```
this is because we allocate the swap scratch in blobvec regardless of what the capacity is, but we only deallocate if capacity is > 0
The second leak:
```rust
#[test]
fn panic_while_overwriting_component() {
let helper = DropTestHelper::new();
let res = panic::catch_unwind(|| {
let mut world = World::new();
world
.spawn()
.insert(helper.make_component(true, 0))
.insert(helper.make_component(false, 1));
println!("Done inserting! Dropping world...");
});
let drop_log = helper.finish(res);
assert_eq!(
&*drop_log,
[
DropLogItem::Create(0),
DropLogItem::Create(1),
DropLogItem::Drop(0),
]
);
}
```
this is caused by us not running the drop impl on the to-be-inserted component if the drop impl of the overwritten component panics
---
managed to figure out where the leaks were by using this 10/10 command
```
cargo --quiet test --lib -- --list | sed 's/: test$//' | MIRIFLAGS="-Zmiri-disable-isolation" xargs -n1 cargo miri test --lib -- --exact
```
which runs every test one by one rather than all at once which let miri actually tell me which test had the leak 🙃
# Objective
- Follow suggestion from https://github.com/bevyengine/bevy/pull/4984#issuecomment-1152949640
## Solution
- Unpin nightly, disable weak memory emulation
---
This failed the miri job in my branch with the following error:
```
error: Undefined Behavior: attempting a read access using <untagged> at alloc198028[0x0], but that tag does not exist in the borrow stack for this location
--> /home/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/once_cell-1.12.0/src/imp_std.rs:177:28
|
177 | let next = (*waiter).next;
| ^^^^^^^^^^^^^^
| |
| attempting a read access using <untagged> at alloc198028[0x0], but that tag does not exist in the borrow stack for this location
| this error occurs as part of an access at alloc198028[0x0..0x8]
|
= help: this indicates a potential bug in the program: it performed an invalid operation, but the rules it violated are still experimental
= help: see https://github.com/rust-lang/unsafe-code-guidelines/blob/master/wip/stacked-borrows.md for further information
```
@BoxyUwU could you take a look? I guess it's related to the issue mentioned in https://github.com/rust-lang/miri/issues/2223
# Objective
- Make Bevy work on android
## Solution
- Update android metadata and add a few more
- Set the target sdk to 31 as it will soon (in august) be the minimum sdk level for play store
- Remove the custom code to create an activity and use ndk-glue macro instead
- Delay window creation event on android
- Set the example with compatibility settings for wgpu. Those are needed for Bevy to work on my 2019 android tablet
- Add a few details on how to debug in case of failures
- Fix running the example on emulator. This was failing because of the name of the example
Bevy still doesn't work on android with this, audio features need to be disabled because of an ndk-glue version mismatch: rodio depends on 0.6.2, winit on 0.5.2. You can test with:
```
cargo apk run --release --example android_example --no-default-features --features "bevy_winit,render"
```
# Objective
CI is now failing with some changes that landed in 1.62.
## Solution
* Fix an unused lifetime by using it (we double-used the `w` lifetime).
* Update compile_fail error messages
* temporarily disable check-unused-dependencies
# Objective
- Have information about examples only in one place that can be used for the repo and for the website (and remove the need to keep a list of example to build for wasm in the website 75acb73040/generate-wasm-examples/generate_wasm_examples.sh (L92-L99))
## Solution
- Add metadata about examples in `Cargo.toml`
- Build the `examples/README.md` from a template using those metadata. I used tera as the template engine to use the same tech as the website.
- Make CI fail if an example is missing metadata, or if the readme file needs to be updated (the command to update it is displayed in the failed step in CI)
## Remaining To Do
- After the next release with this merged in, the website will be able to be updated to use those metadata too
- I would like to build the examples in wasm and make them available at http://dev-docs.bevyengine.org/ but that will require more design
- https://github.com/bevyengine/bevy-website/issues/299 for other ToDos
Co-authored-by: Readme <github-actions@github.com>
# Objective
- Fix timeout in miri
## Solution
- Use a nightly version from before the issue happened: 2022-06-08
- To be checked after https://github.com/rust-lang/miri/issues/2223 is fixed
# 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
While playing with the code, I found some problems in the recently merged version-bumping workflow:
- Most importantly, now that we are using `0.8.0-dev` in development, the workflow will try to bump it to `0.9.0` 😭
- The crate filter is outdated now that we have more crates in `tools`.
- We are using `bevy@users.noreply.github.com`, but according to [Github help](https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-email-preferences/setting-your-commit-email-address#about-commit-email-addresses), that email address means "old no-reply email format for the user `bevy`". It is currently not associated with any account, but I feel this is still not appropriate here.
## Solution
- Create a new workflow, `Post-release version bump`, that should be run after a release and bumps version from `0.X.0` to `0.X+1.0-dev`. Unfortunately, cargo-release doesn't have a builtin way to do this, so we need to parse and increment the version manually.
- Add the new crates in `tools` to exclusion list. Also removes the dependency version specifier from `bevy_ecs_compile_fail_tests`. It is not in the workspace so the dependency version will not get automatically updated by cargo-release.
- Change the author email to `41898282+github-actions[bot]@users.noreply.github.com`. According to the discussion [here](https://github.com/actions/checkout/issues/13#issuecomment-724415212) and [here](https://github.community/t/github-actions-bot-email-address/17204/6), this is the email address associated with the github-actions bot account.
- Also add the workflows to our release checklist.
See infmagic2047#5 and infmagic2047#6 for examples of release and post-release PRs.
# Objective
- Ensure future Bevy releases happens smoothly
## Solution
- Add a workflow that will open a PR updating all Bevy crate that can be created manually
example PR opened: https://github.com/mockersf/bevy/pull/62
The day from this PR does not need to be the release day, it will just open the PR to prepare it. Later if we feel confident, it could push automatically to crates.io.
how to trigger the workflow: https://docs.github.com/en/actions/managing-workflow-runs/manually-running-a-workflow
# 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
1. "What you expected to happen" and "what actually happened" often involves trivial duplication.
2. "Please provide full reproduction steps" is not helpful advice to new contributors.
3. The OS field was commonly useless or inadequate.
4. The description for "additional information" effectively just repeated the title of the field.
## Solution
1. Unify these fields into a single "what went wrong" field.
2. Provide an example of a useful reproduction.
3. Replace OS field with an optional "Setup Information" field that captures information about other critical setup like Rust version and hardware.
4. Provide helpful advice about what sort of information may be useful to add.
# 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
- When Miri is failing, it can be very slow to do so
<img width="1397" alt="Screenshot 2022-05-14 at 03 05 40" src="https://user-images.githubusercontent.com/8672791/168405111-c5e27d63-7a5a-4a5e-b679-abbeeb3201d2.png">
## Solution
- Set the timeout for Miri to 60 minutes (it's 6 hours by default). It runs in around 10 minutes when successful
- Fix cache key as it was set to the same as another task that doesn't build with the same parameters
# Objective
- New PRs are labeled with Needs-Triage, but this is unhelpful and creates busy work: it's just as easy to check for unlabelled PRs, especially now that we no longer have an unlabelled backlog.
Note: this is not true for issues. Issues start with at least one label based on which template they use, and so there's no good way to filter for issues that need attention from the triage team.
## Solution
- Remove responsible CI tasks.
# 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
- Example was misleading, as we never import `bevy` itself in the engine (except in integration tests).
## Solution
- Clean up wording.
## Context
Noticed by @mockersf in #4608.
# Objective
We keep getting issues where things break at small window sizes, e.g #3368 (caused by #3153), #3596 ('caused' by #3545)
## Solution
- Add a test that we can make small windows.
Currently, this fails on my machine with some quite scary vulkan errors:
```
2022-01-08T22:55:13.770261Z ERROR wgpu_hal::vulkan::instance: VALIDATION [VUID-VkSwapchainCreateInfoKHR-imageExtent-01274 (0x7cd0911d)]
Validation Error: [ VUID-VkSwapchainCreateInfoKHR-imageExtent-01274 ] Object 0: handle = 0x1adbd410a60, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x7cd0911d | vkCreateSwapchainKHR() called with imageExtent = (225,60), which is outside the bounds returned by vkGetPhysicalDeviceSurfaceCapabilitiesKHR(): currentExtent = (225,56), minImageExtent = (225,56), maxImageExtent = (225,56). The Vulkan spec states: imageExtent must be between minImageExtent and maxImageExtent, inclusive, where minImageExtent and maxImageExtent are members of the VkSurfaceCapabilitiesKHR structure returned by vkGetPhysicalDeviceSurfaceCapabilitiesKHR for the surface (https://vulkan.lunarg.com/doc/view/1.2.198.1/windows/1.2-extensions/vkspec.html#VUID-VkSwapchainCreateInfoKHR-imageExtent-01274)
2022-01-08T22:55:13.770808Z ERROR wgpu_hal::vulkan::instance: objects: (type: DEVICE, hndl: 0x1adbd410a60, name: ?)
2022-01-08T22:55:13.787403Z ERROR wgpu_hal::vulkan::instance: VALIDATION [VUID-VkSwapchainCreateInfoKHR-imageExtent-01274 (0x7cd0911d)]
Validation Error: [ VUID-VkSwapchainCreateInfoKHR-imageExtent-01274 ] Object 0: handle = 0x1adbd410a60, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x7cd0911d | vkCreateSwapchainKHR() called with imageExtent = (225,56), which is outside the bounds returned by vkGetPhysicalDeviceSurfaceCapabilitiesKHR(): currentExtent = (225,52), minImageExtent = (225,52), maxImageExtent = (225,52). The Vulkan spec states: imageExtent must be between minImageExtent and maxImageExtent, inclusive, where minImageExtent and maxImageExtent are members of the VkSurfaceCapabilitiesKHR structure returned by vkGetPhysicalDeviceSurfaceCapabilitiesKHR for the surface (https://vulkan.lunarg.com/doc/view/1.2.198.1/windows/1.2-extensions/vkspec.html#VUID-VkSwapchainCreateInfoKHR-imageExtent-01274)
```
etc.
This might be a new issue here, although I'm surprised it's vulkan giving this error; wgpu should stop it if this is illegal.
# Objective
- related to #4575, but not a complete fix
- links to GitHub.com can't be checked from inside a GitHub Actions as GitHub is protecting itself from being flooded by an action execution
- it seems they added that protection to GitHub doc site
## Solution
- Ignore links to docs.github.com
# Objective
We are currently asking contributors to "skip" optional sections, which is a bit confusing. "Skip" can be taken to mean that you should "leave that section alone" and result in these bits of template being left in the PR description.
## Solution
Let contributors know that it's okay to delete the section if it's not needed.
Bumps [JamesIves/github-pages-deploy-action](https://github.com/JamesIves/github-pages-deploy-action) from 4.1.7 to 4.3.0.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a href="https://github.com/JamesIves/github-pages-deploy-action/releases">JamesIves/github-pages-deploy-action's releases</a>.</em></p>
<blockquote>
<h2>v4.3.0</h2>
<h2>Changes</h2>
<ul>
<li>Implements a new option available behind a flag, <code>force</code>. If set to <code>false</code> the action will no longer force push, instead attempting 3 times to resolve rejected commits when making parallel/subsequent deployments. In a future version <code>false</code> will be set as the default. Massive thanks to <a href="https://github.com/rossjrw"><code>@rossjrw</code></a> for this feature addition.</li>
<li>Modified the Node version which the action is developed/tested against from <code>14</code> to <code>16</code>.</li>
</ul>
<h2>Minor Changes</h2>
<ul>
<li>Third-party dependency updates.</li>
<li>Test coverage improvements.</li>
</ul>
<h2>v4.2.5</h2>
<h2>Minor Changes</h2>
<ul>
<li>Corrects an issue in the publishing pipeline that was causing workflow failures.</li>
</ul>
<h2>v4.2.4</h2>
<h2>Minor Changes</h2>
<ul>
<li>Modified how workflow notices get displayed. (<a href="https://github-redirect.dependabot.com/JamesIves/github-pages-deploy-action/issues/1033">#1033</a> Thanks to <a href="https://github.com/hemberger"><code>@hemberger</code></a>)</li>
<li>Dependency upgrades.</li>
</ul>
<h2>v4.2.3</h2>
<h2>Minor Changes</h2>
<ul>
<li>Improved action logging. This is part 1 or 2 updates that will make the logs easier to traverse. Warnings and notices are now provided so you don't need to expand the logs to get the termination message.</li>
<li>Dependency bumps across the board.</li>
</ul>
<h2>v4.2.2</h2>
<h2>Minor Changes</h2>
<ul>
<li>Introduces major version tags. You can now point your workflow to <code>JamesIves/github-pages-deploy-action@v4</code> if you'd like to always have the most cutting edge changes outside of using the release branch directly.</li>
<li>The version tags for this project now include a <code>v</code> to be consistent with other officially provided actions by GitHub. You can use <code>JamesIves/github-pages-deploy-action@v4.2.2</code> for instance. Dependabot should pick up this change automatically.</li>
</ul>
<h2>4.2.1</h2>
<h2>Minor Changes</h2>
<ul>
<li>Resolves an issue where the operating system warning was showing incorrectly.</li>
</ul>
<h2>4.2.0</h2>
<h1>Happy New Year 2022!</h1>
<p><img src="https://media.giphy.com/media/pYhFb0kn2GhQQ/giphy.gif" alt="London" /></p>
<h2>Minor Changes</h2>
<ul>
<li>Implements a warning if you're using an unsupported operating system. This will occur if the workflow runs within MacOS or Windows. The workflow will not be cancelled.</li>
<li>The action is now case insensitive, allowing you to make casing changes to files so long as you commit them using the <code>git mv</code> command prior to the workflow running. (<a href="https://github-redirect.dependabot.com/JamesIves/github-pages-deploy-action/issues/895">#895</a>)</li>
<li>Fixes an issue that was causing <code>single-commit</code> to fail when using <code>repository-name</code> if the branch name was equal from the origin to destination. (<a href="https://github-redirect.dependabot.com/JamesIves/github-pages-deploy-action/issues/665">#665</a>)</li>
<li>Enabled Dependabot updates for the GitHub Actions that are used as part of the projects integration tests.</li>
</ul>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a href="360c8e75d0"><code>360c8e7</code></a> Merge branch 'dev' into releases/v4</li>
<li><a href="6ae2891783"><code>6ae2891</code></a> Update integration.yml</li>
<li><a href="e6c302f297"><code>e6c302f</code></a> Update README.md</li>
<li><a href="cf0ab8fab5"><code>cf0ab8f</code></a> Deploy Production Code for Commit 7598e9b3fc39a35565f529abe095d4dfe75d52e4 🚀</li>
<li><a href="7598e9b3fc"><code>7598e9b</code></a> Merge branch 'dev' into releases/v4</li>
<li><a href="36e9415933"><code>36e9415</code></a> Improe coverage</li>
<li><a href="e71f256f1c"><code>e71f256</code></a> Bump prettier from 2.6.1 to 2.6.2 (<a href="https://github-redirect.dependabot.com/JamesIves/github-pages-deploy-action/issues/1068">#1068</a>)</li>
<li><a href="95f8a2cd05"><code>95f8a2c</code></a> Resolve simultaneous deployments with rebase (<a href="https://github-redirect.dependabot.com/JamesIves/github-pages-deploy-action/issues/1054">#1054</a>)</li>
<li><a href="cd846deedd"><code>cd846de</code></a> Bump <code>@actions/github</code> from 5.0.0 to 5.0.1 (<a href="https://github-redirect.dependabot.com/JamesIves/github-pages-deploy-action/issues/1067">#1067</a>)</li>
<li><a href="7117b56a56"><code>7117b56</code></a> Bump prettier from 2.6.0 to 2.6.1 (<a href="https://github-redirect.dependabot.com/JamesIves/github-pages-deploy-action/issues/1065">#1065</a>)</li>
<li>Additional commits viewable in <a href="https://github.com/JamesIves/github-pages-deploy-action/compare/4.1.7...v4.3.0">compare view</a></li>
</ul>
</details>
<br />
[![Dependabot compatibility score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=JamesIves/github-pages-deploy-action&package-manager=github_actions&previous-version=4.1.7&new-version=4.3.0)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
- `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
</details>
Bumps [actions/cache](https://github.com/actions/cache) from 2 to 3.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a href="https://github.com/actions/cache/releases">actions/cache's releases</a>.</em></p>
<blockquote>
<h2>v3.0.0</h2>
<ul>
<li>
<p>This change adds a minimum runner version(node12 -> node16), which can break users using an out-of-date/fork of the runner. This would be most commonly affecting users on GHES 3.3 or before, as those runners do not support node16 actions and they can use actions from github.com via <a href="https://docs.github.com/en/enterprise-server@3.0/admin/github-actions/managing-access-to-actions-from-githubcom/enabling-automatic-access-to-githubcom-actions-using-github-connect">github connect</a> or manually copying the repo to their GHES instance.</p>
</li>
<li>
<p>Few dependencies and cache action usage examples have also been updated.</p>
</li>
</ul>
<h2>v2.1.7</h2>
<p>Support 10GB cache upload using the latest version <code>1.0.8</code> of <a href="https://www.npmjs.com/package/@actions/cache"><code>@actions/cache</code> </a></p>
<h2>v2.1.6</h2>
<ul>
<li>Catch unhandled "bad file descriptor" errors that sometimes occurs when the cache server returns non-successful response (<a href="https://github-redirect.dependabot.com/actions/cache/pull/596">actions/cache#596</a>)</li>
</ul>
<h2>v2.1.5</h2>
<ul>
<li>Fix permissions error seen when extracting caches with GNU tar that were previously created using BSD tar (<a href="https://github-redirect.dependabot.com/actions/cache/issues/527">actions/cache#527</a>)</li>
</ul>
<h2>v2.1.4</h2>
<ul>
<li>Make caching more verbose <a href="https://github-redirect.dependabot.com/actions/toolkit/pull/650">#650</a></li>
<li>Use GNU tar on macOS if available <a href="https://github-redirect.dependabot.com/actions/toolkit/pull/701">#701</a></li>
</ul>
<h2>v2.1.3</h2>
<ul>
<li>Upgrades <code>@actions/core</code> to v1.2.6 for <a href="https://github.com/advisories/GHSA-mfwh-5m23-j46w">CVE-2020-15228</a>. This action was not using the affected methods.</li>
<li>Fix error handling in <code>uploadChunk</code> where 400-level errors were not being detected and handled correctly</li>
</ul>
<h2>v2.1.2</h2>
<ul>
<li>Adds input to limit the chunk upload size, useful for self-hosted runners with slower upload speeds</li>
<li>No-op when executing on GHES</li>
</ul>
<h2>v2.1.1</h2>
<ul>
<li>Update <code>@actions/cache</code> package to <code>v1.0.2</code> which allows cache action to use posix format when taring files.</li>
</ul>
<h2>v2.1.0</h2>
<ul>
<li>Replaces the <code>http-client</code> with the Azure Storage SDK for NodeJS when downloading cache content from Azure. This should help improve download performance and reliability as the SDK downloads files in 4 MB chunks, which can be parallelized and retried independently</li>
<li>Display download progress and speed</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a href="4b0cf6cc46"><code>4b0cf6c</code></a> Merge pull request <a href="https://github-redirect.dependabot.com/actions/cache/issues/769">#769</a> from actions/users/ashwinsangem/bump_major_version</li>
<li><a href="60c606a2b4"><code>60c606a</code></a> Update licensed files</li>
<li><a href="b6e9a919a7"><code>b6e9a91</code></a> Revert "Updated to the latest version."</li>
<li><a href="c842503583"><code>c842503</code></a> Updated to the latest version.</li>
<li><a href="2b7da2a62c"><code>2b7da2a</code></a> Bumped up to a major version.</li>
<li><a href="deae296ab3"><code>deae296</code></a> Merge pull request <a href="https://github-redirect.dependabot.com/actions/cache/issues/651">#651</a> from magnetikonline/fix-golang-windows-example</li>
<li><a href="c7c46bcb6d"><code>c7c46bc</code></a> Merge pull request <a href="https://github-redirect.dependabot.com/actions/cache/issues/707">#707</a> from duxtland/main</li>
<li><a href="6535c5fb5f"><code>6535c5f</code></a> Regenerated <code>examples.md</code> TOC</li>
<li><a href="3fdafa472e"><code>3fdafa4</code></a> Update GitHub Actions status badge markdown in <code>README.md</code></li>
<li><a href="341e6d75d9"><code>341e6d7</code></a> Merge branch 'actions:main' into fix-golang-windows-example</li>
<li>Additional commits viewable in <a href="https://github.com/actions/cache/compare/v2...v3">compare view</a></li>
</ul>
</details>
<br />
[![Dependabot compatibility score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=actions/cache&package-manager=github_actions&previous-version=2&new-version=3)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
- `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
</details>
# Objective
Add a system parameter `ParamSet` to be used as container for conflicting parameters.
## Solution
Added two methods to the SystemParamState trait, which gives the access used by the parameter. Did the implementation. Added some convenience methods to FilteredAccessSet. Changed `get_conflicts` to return every conflicting component instead of breaking on the first conflicting `FilteredAccess`.
Co-authored-by: bilsen <40690317+bilsen@users.noreply.github.com>
# 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
Context: [Discord Discussion](https://discord.com/channels/691052431525675048/745355529777315850/950532143325519902)
Improve the PR template by adding "Changelog" and "Migration Guide" sections. These sections should hopefully help speed up the review/merge process, as well as help make release notes and migration guides.
## Solution
Added the "Changelog" section template which suggests listing out the changes of the PR. This also acts as a sort of tl;dr for reviewers (especially for larger PRs).
Added the "Migration Guide" section template which suggests describing how a user might need to migrate their codebase to account for the changes by the PR. This also helps authors/contributors keep the end-user in mind when adding or changing the API.
Both sections are optional— an author does not _need_ to fill these out. Hopefully they will, though, as it provides a handful of really great benefits.
Co-authored-by: MrGVSV <49806985+MrGVSV@users.noreply.github.com>
# Objective
Partially address #407 by setting up automated deployments of `bevy`'s API reference to GitHub Pages.
## Solution
Set up a GitHub Actions workflow that builds the docs on every push to `main` and pushes a new commit to a `gh-pages` (or `docs` branch).
A few smaller additions to better address #407:
- A top level redirect was added to take "docs.bevyengine.org" directly to the `bevy` crate docs.
- A GitHub Pages CNAME file for supporting a publicly viewable domain instead of `github.io`
- A robots.txt file is added to disable all search engine crawlers that respect it from crawling it (avoid having conflicting Google search results)
- A .nojekyl file to speed up deployments since there is no Jekyll templating in the output.
This may require configuration of the `GITHUB_TOKEN` of the CI to successfully run this.
## Followup
For this to completely resolve#407, a subdomain of https://bevyengine.org/ needs to be set up to point to the CNAME location. This is initially set to "dev-docs.bevyengine.org".
Co-authored-by: Carter Anderson <mcanders1@gmail.com>
Bumps [actions/upload-artifact](https://github.com/actions/upload-artifact) from 1 to 3.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a href="https://github.com/actions/upload-artifact/releases">actions/upload-artifact's releases</a>.</em></p>
<blockquote>
<h2>v3.0.0</h2>
<h2>What's Changed</h2>
<ul>
<li>Update default runtime to node16 (<a href="https://github-redirect.dependabot.com/actions/upload-artifact/issues/293">#293</a>)</li>
<li>Update package-lock.json file version to 2 (<a href="https://github-redirect.dependabot.com/actions/upload-artifact/issues/302">#302</a>)</li>
</ul>
<h3>Breaking Changes</h3>
<p>With the update to Node 16, all scripts will now be run with Node 16 rather than Node 12.</p>
<h2>v2.3.1</h2>
<p>Fix for empty fails on Windows failing on upload <a href="https://github-redirect.dependabot.com/actions/upload-artifact/issues/281">#281</a></p>
<h2>v2.3.0 Upload Artifact</h2>
<ul>
<li>Optimizations for faster uploads of larger files that are already compressed</li>
<li>Significantly improved logging when there are chunked uploads</li>
<li>Clarifications in logs around the upload size and prohibited characters that aren't allowed in the artifact name or any uploaded files</li>
<li>Various other small bugfixes & optimizations</li>
</ul>
<h2>v2.2.4</h2>
<ul>
<li>Retry on HTTP 500 responses from the service</li>
</ul>
<h2>v2.2.3</h2>
<ul>
<li>Fixes for proxy related issues</li>
</ul>
<h2>v2.2.2</h2>
<ul>
<li>Improved retryability and error handling</li>
</ul>
<h2>v2.2.1</h2>
<ul>
<li>Update used actions/core package to the latest version</li>
</ul>
<h2>v2.2.0</h2>
<ul>
<li>Support for artifact retention</li>
</ul>
<h2>v2.1.4</h2>
<ul>
<li>Add Third Party License Information</li>
</ul>
<h2>v2.1.3</h2>
<ul>
<li>Use updated version of the <code>@action/artifact</code> NPM package</li>
</ul>
<h2>v2.1.2</h2>
<ul>
<li>Increase upload chunk size from 4MB to 8MB</li>
<li>Detect case insensitive file uploads</li>
</ul>
<h2>v2.1.1</h2>
<ul>
<li>Fix for certain symlinks not correctly being identified as directories before starting uploads</li>
</ul>
<h2>v2.1.0</h2>
<ul>
<li>Support for uploading artifacts with multiple paths</li>
<li>Support for using exclude paths</li>
<li>Updates to dependencies</li>
</ul>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a href="6673cd052c"><code>6673cd0</code></a> Update <code>lockfileVersion</code> in <code>package-lock.json</code> (<a href="https://github-redirect.dependabot.com/actions/upload-artifact/issues/302">#302</a>)</li>
<li><a href="2244c82003"><code>2244c82</code></a> Update to node16 (<a href="https://github-redirect.dependabot.com/actions/upload-artifact/issues/293">#293</a>)</li>
<li><a href="87348cee5f"><code>87348ce</code></a> Add 503 warning when uploading to the same artifact</li>
<li><a href="82c141cc51"><code>82c141c</code></a> Bump <code>@actions/artifact</code> to version 0.6.1 (<a href="https://github-redirect.dependabot.com/actions/upload-artifact/issues/286">#286</a>)</li>
<li><a href="da838ae959"><code>da838ae</code></a> Bump <code>@actions/artifact</code> to version 0.6.0 (<a href="https://github-redirect.dependabot.com/actions/upload-artifact/issues/280">#280</a>)</li>
<li><a href="f4ac36d205"><code>f4ac36d</code></a> Improve readme (<a href="https://github-redirect.dependabot.com/actions/upload-artifact/issues/278">#278</a>)</li>
<li><a href="5f375cca4b"><code>5f375cc</code></a> Document how to correctly use environment variables for path input (<a href="https://github-redirect.dependabot.com/actions/upload-artifact/issues/274">#274</a>)</li>
<li><a href="a009a66585"><code>a009a66</code></a> Create release-new-action-version.yml (<a href="https://github-redirect.dependabot.com/actions/upload-artifact/issues/277">#277</a>)</li>
<li><a href="b9bb65708e"><code>b9bb657</code></a> Bump tmpl from 1.0.4 to 1.0.5 (<a href="https://github-redirect.dependabot.com/actions/upload-artifact/issues/250">#250</a>)</li>
<li><a href="0b3de3e43b"><code>0b3de3e</code></a> Fix <code>README.md</code> links and some formatting updates (<a href="https://github-redirect.dependabot.com/actions/upload-artifact/issues/273">#273</a>)</li>
<li>Additional commits viewable in <a href="https://github.com/actions/upload-artifact/compare/v1...v3">compare view</a></li>
</ul>
</details>
<br />
[![Dependabot compatibility score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=actions/upload-artifact&package-manager=github_actions&previous-version=1&new-version=3)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
- `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
</details>
Bumps [actions/labeler](https://github.com/actions/labeler) from 3 to 4.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a href="https://github.com/actions/labeler/releases">actions/labeler's releases</a>.</em></p>
<blockquote>
<h2>v4.0.0</h2>
<ul>
<li><a href="https://github-redirect.dependabot.com/actions/labeler/pull/319"> Update to node 16 runtime</a></li>
</ul>
<h2>v3.1.0</h2>
<p>Dependency upgrades, docs updates, and behind-the-scenes maintenance.</p>
<p>See the full list of changes since 3.0.2 here: <a href="https://github.com/actions/labeler/compare/v3.0.2...v3.1.0">https://github.com/actions/labeler/compare/v3.0.2...v3.1.0</a></p>
<p>Thanks to <a href="https://github.com/GisoBartels"><code>@GisoBartels</code></a> and <a href="https://github.com/Muhammed-Rahif"><code>@Muhammed-Rahif</code></a> for their contributions!</p>
<h2>v3.0.2</h2>
<p>No API changes, but lots of behind-the-scenes upgrades, mostly to internal dependencies, tooling, and surrounding infrastructure.</p>
<h2>v3.0.1</h2>
<p>No user-facing changes.</p>
<p>That said, there were more than enough behind-the-scenes changes to warrant a new release: <a href="https://github.com/actions/labeler/compare/v3.0.0...v3.0.1">https://github.com/actions/labeler/compare/v3.0.0...v3.0.1</a></p>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a href="9fd24f1f9d"><code>9fd24f1</code></a> Merge pull request <a href="https://github-redirect.dependabot.com/actions/labeler/issues/334">#334</a> from actions/thboop/updatetov4</li>
<li><a href="abae52fa24"><code>abae52f</code></a> Update to new v4 release</li>
<li><a href="e1132f5ed5"><code>e1132f5</code></a> Merge pull request <a href="https://github-redirect.dependabot.com/actions/labeler/issues/319">#319</a> from actions/thboop/node16update</li>
<li><a href="b0cc574b25"><code>b0cc574</code></a> Update build_test.yml</li>
<li><a href="c48e531900"><code>c48e531</code></a> Update default runtime to node16</li>
<li>See full diff in <a href="https://github.com/actions/labeler/compare/v3...v4">compare view</a></li>
</ul>
</details>
<br />
[![Dependabot compatibility score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=actions/labeler&package-manager=github_actions&previous-version=3&new-version=4)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
- `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
</details>
# Objective
- Using the `cargo run -p ci` command locally is unreliable, as it does not run tests.
- This is particularly unreliable for doc tests, as they are not run as part of `cargo test`.
## Solution
- add more steps to the appropriate Rust file.
## Known Problems
This duplicates work done to run tests when run on Github. @mockersf, suggestions on if we care / how we can mitigate it?
# Objective
Fixes#3566
## Solution
- [x] Fix broken links in private docs.
- [x] Add the `--document-private-items` flag to the CI.
## Note
The following was said by @killercup in #3566:
> I don't have time to confirm this but I assume that linking to private items throws an error/warning when just running cargo doc, and --document-private-item might actually hide that warning. So to test this, you'd have to run it twice.
I tested this and this is thankfully not the case. If you are linking to a private item you will get a warning no matter if you run `cargo doc` or `cargo doc --document-private-items`.
### Example
I added `struct Test;` to `bevy_core/src/name.rs` and linked to it inside of a doc comment using ``[`Test`]``. After that I ran `cargo doc -p bevy_core --document-private-items` using `RUSTDOCFLAGS="-D warnings"` and got the following output (note the last sentence):
```rust
error: public documentation for `Name` links to private item `Test`
--> crates/bevy_core/src/name.rs:11:82
|
11 | /// Component used to identify an entity. Stores a hash for faster comparisons [`Test`]
| ^^^^ this item is private
|
= note: `-D rustdoc::private-intra-doc-links` implied by `-D warnings`
= note: this link resolves only because you passed `--document-private-items`, but will break without
```
Closes#3497.
I added the rust API guidelines (https://rust-lang.github.io/api-guidelines/about.html) to the `CONTRIBUTING.md` file.
## Note
As noted in #3497 we should note any areas where we deliberately disagree as they arise. If we start adding these areas it might be a good idea to remove the mention of the `API guidelines` in the `CONTRIBUTING.md` file and move it to the `engine_style_guide.md`. That way we still have the connection between the `CONTRIBUTING.md` and the `API guidelines`, but we have more "space" to work with and can go into more detail about what we agree and disagree on.
For now I would leave it this way, because it's one less click to get to the guidelines.
Co-authored-by: KDecay <KDecayMusic@protonmail.com>
# 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>