mirror of
https://github.com/bevyengine/bevy
synced 2024-11-10 15:14:50 +00:00
c4080c6832
# 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. |
||
---|---|---|
.. | ||
src | ||
tests | ||
Cargo.toml | ||
README.md |
Compile fail tests for bevy_ecs
This crate is separate from bevy_ecs
and not part of the Bevy workspace in order to not fail crater
tests for Bevy. The tests assert on the exact compiler errors and can easily fail for new Rust versions due to updated compiler errors (e.g. changes in spans).
The CI
workflow executes these tests on the stable rust toolchain (see tools/ci).