We'd like to enable the "default commit message: pull request title and body" option for squash merges. That means we need PR bodies to be clean, and do not want HTML comments like this template to end up becoming part of the commit message body.
We'd like to enable the "default commit message: pull request title and body" option for squash merges. That doesn't currently work well for dependabot PRs, because the PR body includes rich HTML.
Therefore, this commit introduces a new workflow which replaces any dependabot PR bodies with plaintext content from the commit message. The original rich content will be added in a comment.
In 15a7a84d84, I changed the `linting`
workflow to run on `ubuntu-latest` because it is free and helps to free
up our self hosted runners for more important workflow jobs. However,
some devs rely on the `linting` workflow for feedback so we want to
provide this feedback as soon as we can. Therefore, we are putting the
`linting` workflow back on our faster self hosted runners.
Our self hosted runners are limited in quantity so we should preserve
them for workflows that actually require the additional resources
instead of tying them up on workflows that do not benefit from the
additional resources.
This commit updates the tests workflow to use the `discourse/discourse_test:release` image. This allows us to drop the some usage of Github actions cache which can be quite slow to fetch from our self hosted runners.
We are running on self hosted runners with more CPU and RAM so we should
be able to run one system test process per CPU core for more speedz.
This may lead to some instability in our system tests but it is hard to say unless we roll this change out. If it does lead to system tests being more unstable, we can easily roll back the change.
On our own self hosted runners, pulling from github actions cache is quite slow and can take up to 20 seconds for the `bundler cache` step. Instead, we will now copy the gems from the `/var/www/discourse/vendor/bundle` folder in the `discourse/discourse_test:release` image which is built daily. This eliminates the need to pull from Github actions cache and also potentially reduces our costs of cache storage.
Note that `discourse/discourse_test:release` is pulled periodically on our self hosted runners so there is no impact on the time it takes to initialize the container.
This switches us back to the 'unstable' version of Glint, which is 'Volar' under the covers. While it's still a work-in-progress, it already works much better for us than the 'stable' version of Glint.
The CI check makes sure that we don't re-introduce any ts/glint-incompatible changes in future (e.g. object literal property decorators).
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.
* DEV: update pull request template with more details of what is expected in a PR
Added information:
- We expected the pr to have a title that is descriptive of the changes
- Good commit messages and prefixes
- If the pull request had UX/UI changes to include screenshots
- If changing flaky tests to include the reason for the change
* Update .github/pull_request_template.md
Co-authored-by: David Taylor <david@taylorhq.com>
---------
Co-authored-by: David Taylor <david@taylorhq.com>
* Updates GitHub Actions
* Switches from `bundler/inline` to an optional group in the `Gemfile` because the previous solution didn't work well with rspec
* Adds the converter framework and tests
* Allows loading private converters (see README)
* Switches from multiple CLI tools to a single CLI
* Makes DB connections reusable and adds a new abstraction for the `IntermediateDB`
* `IntermediateDB` acts as an interface for IPC calls when a converter steps runs in parallel (forks). Only the main process writes to the DB.
* Includes a simple example implementation of a converter for now.
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.
