This new check will ensure that all commit message lines are at most 72
characters long, as well as ensure the commit title conforms to the
"Category: Brief description of what's being changed" format.
Initially this was configured to 2 an hour so that we could easily
disable stale-bot if something went haywire. Now that it's successfully
proved it's doing what it's supposed to, let it run the default number
of actions per hour.
This change adds the required configuration to setup the
https://github.com/probot/stale github bot to close stale pull requests.
We currently have a large amount of PRs just sitting around with no
activity, clogging up the PR queue. This will hopefully make that
situation better.
Since some builds can take even longer than 1 hour
(for example: f033416893)
this commit just increases the timeout to be github's
own workflow timeout (effectively disabling it) and just
lets github handle it instead.
The previous filter would filter out queued checks as well, which would
result in erroneous build success notifications going out if github
started the discord notifications workflow before all other workflows.
Since our tests usually take at least 10 minutes theres no point in
checking every 10 seconds, and github was starting to complain about
the very high API usage.
It looks like some particularly long builds (After a toolchain cache
reset and on a slow worker) can take much longer than the current set
timeout of 20 minutes.
While we did allow the notify_discord job to run inside the context,
we didnt ask github to run in that context. This commit also uses the
"action-wait-for-check" sub-action to ensure the posted build results
are accurate for pull requests (since the build workflow is done in a
separate context for PRs)
If the job fails early (e.g. during linting), the 'cat debug.log' step would *also* fail.
This would confuse GA into thinking that this is the crucial thing and highlights it.
This misleads the user into looking at the wrong thing.
As documented in #5541, there are some Kernel issues that can
sporadically cause the test run to fail. Add continue on error with a
loud comment to let readers know what the issue(s) might be.
Build a new version of Serenity in CI that doesn't have all the debug
symbols on, or we'd be waiting a very long time to boot.
Insert a TestRunner entry into SystemServer.ini that will run a shell
script that runs tests in /bin and /usr/Tests and shuts down the system
in the new self-test boot mode. Also make sure enough basic services are
started in self-test such that the tests will actually run properly.
This will make it easier to keep macos tests and non-mac tests in
lockstep. Also, make sure flake8 and python are installed. This also
makes it easier to add other OS targets if we want.
* Add SERENITY_ARCH option to CMake for selecting the target toolchain
* Port all build scripts but continue to use i686
* Update GitHub Actions cache to include BuildIt.sh
A good number of contributors use macOS. However, we have a bit of
a tendency of breaking the macOS build without realising it.
Luckily, GitHub Actions does actually supply macOS environments,
so let's use it.
CMake tests usually takes ~40 seconds. However, sometimes it deadlocks
and is only timed out after the 6 hour time limit.
Let's set a 2 minute timeout to make it fail sooner. 2 minutes instead
of 1 for good measure.
There are cases where Lagom will build with GCC but not Clang.
This often goes unnoticed for a while as we don't often build with
Clang.
However, this is now important to test in CI because of the
OSS-Fuzz integration.
Note that this only tests the build, it does not run any tests.
Note that it also only builds LagomCore, Lagom and the fuzzers.
It does not build the other programs that use Lagom.
CodeQL is a static analysis technology that was purchased by GitHub
and has been tightly integrated into the platform. It's different
from most other static analysis solutions because it's based on a
database built from your codebase, and then language specific rules
can be executed against that database. The rules are fully user
extensible, and are written in a datalog/query language.
The default cpp language rules coming from CodeQL will probably find
some issues, the ability to easily write custom rules/queries will
lend it self nicely to allowing us to validate Serenity specific
semantics are followed throughout the code.
References:
- https://www.youtube.com/watch?v=AMzGorD28Ks
- https://securitylab.github.com/tools/codeql
