`run-qunit.js` does not expect QUnit tests to start automatically but
our wizard QUnit setup did not respect the `qunit_disable_auto_start`
URL param. Hence, tests would start running automatically and when a
subsequent `QUnit.start()` function call is made, we ended up getting a
`QUnit.start cannot be called inside a test context.` error.
This error can be consistently reproduced in the `discourse:discourse_test` container but not in
the local development environment. I do not know why and did not feel
like it is important at this point in time to know why.
Previously, if Core QUnit 1 failed, then QUnit 2/3 wouldn't even be attempted. When dealing with multiple failures, this can make the feedback cycle. Setting `if: always()` ensures that the steps run regardless of any earlier failures. This is the same approach we take in the linting workflow.
We have 3 branches which we care about, `main`, `beta` and `stable`.
However, each of this branch has different compatibilties with plugins
and we want to respect that.
This reverts commit f43bba8d59.
Adding randomness has introduced a lot of flakiness in our ember-cli tests. We should fix those issues at the source. However, given the upcoming stable release, this randomness has been reverted so that the stable release includes a stable test suite. Having a stable test suite on stable will make backporting future commits much easier.
- Move ember-cli tests into the main test workflow, so they're listed alongside other tests
- Remove the 'experimental' label
- Add the 'legacy' label to old-style qunit tests
- Add core-plugin EmberCLI tests
- Add scaffolding for all-plugin EmberCLI tests, but disable in matrix for now
The discourse base image already contains a postgres installation, so pulling a separate postgres image is a little wasteful. Using the copy of Postgres in the discourse image saves about 20 seconds on every GitHub actions run.
This commit sets up Postgres with a few performance-improving flags, which we were already using for the `rake docker:test` task (used on our internal CI system).
A cached database (and its uploads) will only be used if the current run has exactly the same set of migration files. Otherwise, the database will be migrated from scratch
This saves approximately 75s on the core backend specs and 45s on other runs.
`bin/rake annotate` is an alias of `bin/annotate --models`
`bin/rake annotate:clean` generates annotations by using a temporary, freshly migrated database. This should help us to produce more consistent annotations, even if development databases have been polluted by plugin migrations.
A GitHub actions task is also added which generates annotations on a clean database, and raises an error if they differ from the committed annotations.
Includes:
* DEV: Remove external plugin linting (that's covered by CI in their repositories)
* DEV: Move lint stages to a separate workflow (partial de-`if`-ication of workflows)
* DEV: Run CI on `main` branch too
* DEV: Update postgres to 13
* DEV: Update redis to 6.x
Other changes:
* DEV: Remove matrix.os
* DEV: Remove env.BUILD_TYPE
* DEV: Remove env.TARGET
* DEV: Rename `build_types` config option to `build_type`
* DEV: Lowercase `target` and `build_type` names
* DEV: Rename `ci` to `tests`
* DEV: Rename `lint` to `linting`
* DEV: Lower the wizard qunit timeout (30 min -> 10)
* DEV: Ruby version is no longer configurable
* DEV: Run plugin tests only in the `plugins` target
* DEV: Use binstubs where applicable
* DEV: We don't open PRs to `tests-passed`
Alan Guo Xiang Tan
Jarek Radosz
David Taylor
dependabot[bot]
Robin Ward
Penar Musaraj