# Objective
The weekly beta compile test workflow can be useful to people who have
forked the repository.
However, there are a few small issues with how this workflow is
currently set up:
* Scheduled workflows run on the base/default branch, with no way
(currently) to change this. On forks, the base/default branch is usually
kept in sync with the main Bevy repository, meaning that running this
workflow on forks would just be a waste of resources. (See
[here](https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#schedule)
- "Scheduled workflows will only run on the default branch.")
* Even if there was a way to change the branch that a scheduled workflow
runs on, forks default to not having an issue tracker.
* Even in the event that a fork's issue tracker is enabled, most users
probably don't want to receive automated issues in the event of a
compilation failure.
Because of these reasons, this workflow is irrelevant for 99% of forks.
## Solution
We now skip all jobs on the `Weekly beta compile test` workflow, if we
detect we're running this workflow on a fork.
## Testing
Testing? Who needs testing? (Seriously though, I made sure the syntax is
correct.)
# Objective
- Many of our CI workflows contain a `NIGHTLY_TOOLCHAIN` environmental
variable.
- This specifies which nightly to use. If there is a bug in one of the
nightlies, we can pin the toolchain to be an earlier version.
- Both the daily and weekly workflows do not use the nightly compiler,
but still have a `NIGHTLY_TOOLCHAIN` variable.
## Solution
- Delete the unused variable.
# Objective
- There are several occurrences where different actions install alsa,
udev, and various other libraries for Linux.
- This is repetitive and can be an issue if the dependencies required by
Bevy ever change.
## Solution
- Create a custom action for installing Linux dependencies.
- It can be used by adding `- uses:
./.github/actions/install-linux-deps`.
- It supports configuring which libraries are installed using the `with`
property.
- It does nothing if not run on Linux, so workflows don't need to worry
about adding `if: ${{ runner.os == 'linux' }}`.
## Discussion
- The only instance where this action is not used cleanly is for the
`run-examples-linux-vulkan` verification job. I need to investigate
further the flags and dependencies that it installs.
# Objective
Get an early warning if any new rust lints will break CI. Closes#12625
## Solution
Test the main branch against the Rust beta every week.
## Additional Possibilities
The action currently creates an issue if anything fails. The issue could
use a label like `C-Weekly` but somebody with the ability to create
issue labels would have to add it.
Another possibility would be to use discord webhooks. That would need
somebody with the access to create webhooks on discord and somebody with
the rights to connect that webhook to this repo,
