The aim of the flaky-tests-rerun system is to reduce the amount of time developers have to spend manually restarting CI jobs. That means that, to get the benefit, we need to run it for PRs as well as on `main`.
Our internal reporting system only looks at the data from runs on `main`, so that it's not polluted by legitimately failing tests in PRs.
Seeing errors like the following which is normally due to us running
too many processes.
```
not ok 292 Firefox - [undefined ms] - error
---
message: >
Error: Browser timeout exceeded: 10s
Error while executing test: Acceptance: Uppy Composer Attachment - Multiple Upload Errors: should show a consolidated message for multiple failed uploads
Stderr:
*** You are running in headless mode.
Stdout:
[GFX1-]: glxtest: libpci missing
[GFX1-]: glxtest: Unable to open a connection to the X server
[GFX1-]: No GPUs detected via PCI
[GFX1-]: RenderCompositorSWGL failed mapping default framebuffer, no dt
```
docker.io rate limits _should_ be addressed now. Switch back to
`debian-12` runners.
This is now a conditional within the `tests` workflow as we evaluate the
migration.
This reverts commit a99e2c62e6.
The self-hosted Github runners have been provisioned, and we can switch
to using them for evaluation.
To prefer Github-hosted runners, you can safely revert this commit.
See: t/123181.
This will bring significant improvements to install speed & storage requirements. For information on how it may affect you, see https://meta.discourse.org/t/324521
This commit:
- removes the `yarn.lock` and replaces with `pnpm-lock.yaml`
- updates workspaces to pnpm format
- adjusts package dependencies to work with pnpm's stricter resolution strategy
- updates Rails app to load modules from more specific node_modules directories
- adds a `.pnpmfile` which automatically cleans up old yarn-managed `node_modules` directories
- updates various scripts to call `pnpm` instead of `yarn`
- updates patches to use pnpm's native patch system instead of patch-package
- adds a patch for licensee to support pnpm
This regressed in b83a2a34a4 because the
Github actions docs doesn't make it clear that `runner.name` is actually
the runner's name plus some unique string appended at the end. Why they
would do that is beyond me.
We cannot just key on `runner.os` the number of CPU cores matter as
well. Therefore, we need to key on `runner.name` instead since each
runner has its own unique OS and CPU cores. Technically, two different
runner with different names can have the same `os` and `cpu cores` but
we don't have that problem now.
QUnit tests are failing in different ways on Chromium in Debian
bookworm. We have no interest in figuring out why as it is not a good
use of our time and the long term plan is to switch to Chrome for Testing
anyway.
Previously "themes frontend" CI job would:
1. pull compatible versions of themes that happened to be in the base image
2. clone all official themes (overriding the compatible versions from 1.)
3. run tests
`discourse-ai` has custom gems which need to be bumped in order to be
compatible with Ruby 3.3. However, its version is pinned so we can't
pull in the commits in which upgrades the gems to be compatible with
Ruby 3.3. Just avoid running the specs on `stable` branch for now until
we release a new stable.
This commit adds a step in our tests workflow on Github actions to update the themes to
use the compatible version when not running aginast the `main` branch.
This is to ensure that we are not running
the tests for themes against an incompatible version of Discourse.
Why this change?
Bundle cache should be keyed on ruby version as well as the debian
release name. Changes to the debian release can affect the way gems are
installed since gems may link to different versions of binaries.
The version of Chromium we have in our images (120) is relatively
unstable and our system specs break regularly.
This patch makes sure Chrome is used instead for system specs.
Why this change?
We run on different runners depending on the scenario. We should use the
right number of parallel jobs for bundle install based on the number of
CPU cores the runner has.
This is so the CI output on GitHub actions isn't showing
tons and tons of unnecessary log data every time you want
to see the important thing, which is the actual test failure.
Why this change?
The output is too verbose and prevents us from quickly identifying tests
failures. Now that our tests are way more stable and less flaky, we can
drop the documentation format since we do not need it for debugging
purposes that often anymore
