Building the Discourse JS app is very resource-intensive. This commit
introduces an `assemble_ember_build` script which will check the
existing content of the `dist/` directory and re-use the core build if
possible. Plugins will always be rebuilt.
For now, this functionality is only useful for multi-stage (i.e.
non-standard) Discourse deployments. But in future, this script may be
extended to pull the contents of the `dist/` directory from a remote
location.
* Splits the existing script into multiple classes
* Adds command for generating IntermediateDB schema (`migrations/bin/cli schema generate`)
* Changes the syntax of the IntermediateDB schema config
* Adds validation for the schema config
* It uses YAML schema aka JSON schema to validate the config file
* It generates the SQL schema file and Ruby classes for storing data in the IntermediateDB
* Updates GitHub Action for migrations
* Rubocop: Always `EnforcedShorthandSyntax` for hashes in the `migrations` directory
* Automatically load all available converter steps
* Enable YJIT at runtime, if available
* Progressbar shows skipped records and other small improvements
There are flaky system tests that have been exhausting the 10 seconds
default max wait time which we have set previously on CI. However, I
have yet to be able to figure out why and lack the tools to be able to
figure out why. The hope here is that the upcoming playwright driver
will provide us with better tooling to debug such problems.
I've attempted to use `Capybara::Session#using_wait_time` by there is
some race condition going on where the session's default max wait time
is sometimes not set properly. I can't figure out why and have spent too
much time trying to figure out why. Instead, I will just bump up the
`default_max_wait_time` to `20`. This may the build take longer when
there are test failures but it is a trade-off we will make right now.
In the `discourse/discourse_test:release` base image, the minio binaries
are already being installed and updated on a daily basis. There is also
no
real need for us to have to run the latest minio binaries once it is
released. As such, we can drop the step in the `tests` workflow.
This totally separate SCSS and i18n compilation pipelines only existed
so that we could run `ember exam` in CI without starting Rails.
Now that our CI has such heavy caching of Ruby dependencies and database
migrations, the speed benefit of this is not worth the cost of
maintaining these separate pipelines.
Therefore, this commit removes that system, and updates CI to use
`bin/rake qunit:test`. That will start up a Rails server and proxy
stylesheet/locale requests to it. This strategy was already used for our
theme and plugin qunit test runs.
This repo was archived in March 2024 and is no longer supported.
Commit also fixes up the plugin-gem-symlinking logic to support removing
plugins from the list
This could cause assets (e.g. fonts) to try and load from
`www.example.com`, which led to an error. In the case of theme-qunit
tests this actually caused the run to fail. Not entirely sure why...
font failures shouldn't be catastrophic... but this is a good fix
regardless.
Stylelint is a css linter: https://stylelint.io/
As part of this change we have added two javascript scripts:
```
pnpm lint:css
pnpm lint:css:fix
```
Look at `.vscode/settings.json.sample` and `.vscode/extensions.json` for
configuration in VSCode.
---------
Co-authored-by: Joffrey JAFFEUX <j.jaffeux@gmail.com>
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 15a7a84d84bb97742263228c7cd043ab6deeae18, 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.
This reverts commit 387f2c52e65ef48ea734fbfdfa34f2e28d3493fb.
Merging fails if there are no artifacts matching the pattern. Reverting while we work out a path forward
