Commit Graph

68 Commits

Author SHA1 Message Date
David Taylor 6417173082
DEV: Apply syntax_tree formatting to `lib/*` 2023-01-09 12:10:19 +00:00
David Taylor 0c743a591f
DEV: Allow `rake qunit` filter to be used alongside parallel option (#18326)
Followup to 61f5c8716d
2022-09-22 10:28:02 +01:00
Sergei Mellow 61f5c8716d
DEV: Update `rake qunit:test` to support filtering (#18249) 2022-09-21 14:00:50 -04:00
David Taylor e06b9d4a52
DEV: Remove support for legacy plugin JS compilation pipeline (#18293)
This became the default in b1755137
2022-09-21 12:38:02 +01:00
David Taylor ce21205d39
DEV: Add support for running plugin qunit in parallel (#18291)
For example, to run in three concurrent browsers and assemble the results:

```
QUNIT_PARALLEL=3 bin/rake "plugin:qunit[discourse-chat]"
```
2022-09-20 18:11:26 +01:00
Jarek Radosz 2c1fc28d00
DEV: Remove ember-cli flags from the backend (#17147)
…and other auxiliary code

* Restore `QUNIT_EMBER_CLI` flag warning
* Add `ALLOW_EMBER_CLI_PROXY_BYPASS`
2022-06-20 16:33:05 +02:00
David Taylor 12980418ae
DEV: Disable the use of 'legacy' Ember assets (#17127)
Anyone still using `EMBER_CLI_PROD_ASSETS=0` in development or production will be gracefully switched to Ember CLI. In development, a repeated message will be logged to STDERR.

Similarly, passing `QUNIT_EMBER_CLI=0` to the qunit rake task will now do nothing. A warning will be printed, and ember-cli mode will be used. Note that we've chosen not to fail the task, so that existing plugin/theme CI jobs don't immediately start failing. We may switch to a hard fail in the coming days/weeks.
2022-06-17 16:51:28 +01:00
David Taylor 127ba698a7
DEV: Allow running theme-qunit tests via testem (#16540)
This allows `QUNIT_EMBER_CLI=1 bin/rake theme:qunit[...]` to test themes using `testem` with Ember-CLI-generated assets
2022-04-22 15:04:01 +01:00
Jarek Radosz 1209d51a7f
DEV: Don't use `Dir.chdir()` (#16535)
`system()` provides `chdir:` option for that.
2022-04-22 11:17:10 +02:00
David Taylor 22a7905f2d
DEV: Allow Ember CLI assets to be used by development Rails app (#16511)
Previously, accessing the Rails app directly in development mode would give you assets from our 'legacy' Ember asset pipeline. The only way to run with Ember CLI assets was to run ember-cli as a proxy. This was quite limiting when working on things which are bypassed when using the ember-cli proxy (e.g. changes to `application.html.erb`). Also, since `ember-auto-import` introduced chunking, visiting `/theme-qunit` under Ember CLI was failing to include all necessary chunks.

This commit teaches Sprockets about our Ember CLI assets so that they can be used in development mode, and are automatically collected up under `/public/assets` during `assets:precompile`. As a bonus, this allows us to remove all the custom manifest modification from `assets:precompile`.

The key changes are:
- Introduce a shared `EmberCli.enabled?` helper
- When ember-cli is enabled, add ember-cli `/dist/assets` as the top-priority Rails asset directory
- Have ember-cli output a `chunks.json` manifest, and teach `preload_script` to read it and append the correct chunks to their associated `afterFile`
- Remove most custom ember-cli logic from the `assets:precompile` step. Instead, rely on Rails to take care of pulling the 'precompiled' assets into the `public/assets` directory. Move the 'renaming' logic to runtime, so it can be used in development mode as well.
- Remove fingerprinting from `ember-cli-build`, and allow Rails to take care of things

Long-term, we may want to replace Sprockets with the lighter-weight Propshaft. The changes made in this commit have been made with that long-term goal in mind.

tldr: when you visit the rails app directly, you'll now be served the current ember-cli assets. To keep these up-to-date make sure either `ember serve`, or `ember build --watch` is running. If you really want to load the old non-ember-cli assets, then you should start the server with `EMBER_CLI_PROD_ASSETS=0`. (the legacy asset pipeline will be removed very soon)
2022-04-21 16:26:34 +01:00
Jarek Radosz bf8dc394bd
DEV: Add chromium to ChromeInstalledChecker (#16224) 2022-03-19 11:00:06 +01:00
David Taylor 5c23c6cdab DEV: Update `rake qunit:test` and `rake plugin:qunit` to use `testem`
For now this is still gated behind a `QUNIT_EMBER_CLI=1` environment variable, but will eventually become the default so that we can remove `run-qunit.js`.
2022-01-18 10:16:29 +00:00
Jarek Radosz df6e8b924e
DEV: Make legacy ember tests less likely to fail (#15147)
…on launch
2021-12-01 19:30:33 +01:00
David Taylor 89994cff40 DEV: Allow Ember CLI for `rake qunit:test` and `rake plugin:qunit`
To use Ember CLI, set QUNIT_EMBER_CLI=1
2021-09-21 18:10:04 +01:00
Osama Sayegh d3a3d1b94c
DEV: Introduce `TemporaryRedis` and unset `DISCOURSE_*` env vars in the `themes:isolated_test` rake task (#13401)
The `themes:isolated_test` rake task will now unset all `DISCOURSE_*` env variables if `UNSET_DISCOURSE_ENV_VARS` env var is set and will also spin up a temporary redis server so the unicorn web server that's spun up for the tests doesn't leak into the "main" redis server.
2021-06-23 07:38:43 +03:00
Martin Brennan 7b31d8a11b
DEV: Move chrome binary check into a shared lib (#13451)
We had checks for the chrome binary in 3 different places
for tests and only one of them checked for google-chrome-stable,
which is problematic for Arch linux users (there are dozens of us!)

This PR moves all the code to one place and references it instead
of copying and pasting.
2021-06-21 13:28:48 +10:00
Osama Sayegh 503017474c
DEV: Skip CSS watcher when running QUnit tests and expose more Chrome logs (#13390)
There are 2 changes in this PR:

1) Add a new environment variable called `DISCOURSE_SKIP_CSS_WATCHER` to disable our stylesheet watcher, and make the `qunit:test` rake task set this variable on the Unicorn/Rails server it spins up to disable our stylesheet watcher when running the tests because it doesn't really need it.

2) Print more Chrome logs (such as network/security errors) to the console.
2021-06-15 18:27:15 +03:00
Jarek Radosz 3bb765ac92
DEV: Remove the remaining Travis code (#13255)
The second attempt at #10041 now that all our plugins use GitHub Actions CI instead.
2021-06-02 20:29:47 +02:00
Osama Sayegh 4f88f2eb15
FEATURE: Allow theme tests to be run in production (take 2) (#12845)
This commit allows site admins to run theme tests in production via a new `/theme-qunit` route. When you visit `/theme-qunit`, you'll see a list of the themes/components installed on your site that have tests, and from there you can select a theme or component that you run its tests.

We also have a new rake task `themes:install_and_test` that can be used to install a list of themes/components on a temporary database and run the tests of the themes/components that are installed. This rake task can be useful when upgrading/deploying a Discourse instance to make sure that the installed themes/components are compatible with the new Discourse version being deployed, and if the tests fail you can abort the build/deploy process so you don't end up with a broken site.
2021-04-28 23:12:08 +03:00
Osama Sayegh a169dc6832
Revert "FEATURE: Allow theme tests to be run in production (#12815)" (#12840)
This reverts commit 7217dcb67a.

https://meta.discourse.org/t/failed-to-bootstrap-due-to-out-of-memory-killer/188141/18?u=osama

Precompiling test_helper.js is so expensive that it can make bootstrap
fail on servers with limited resources (2GB RAM). We will find another
way that doesn't require much resources.
2021-04-26 23:05:58 +03:00
Osama Sayegh 7217dcb67a
FEATURE: Allow theme tests to be run in production (#12815)
This commit allows site admins to run theme tests in production via a new `/theme-qunit` route. When you visit `/theme-qunit`, you'll see a list of the themes/components installed on your site that have tests, and from there you can select a theme or component that you run its tests.

We also have a new rake task `themes:install_and_test` that can be used to install a list of themes/components on a temporary database and run the tests of the themes/components that are installed. This rake task can be useful when upgrading/deploying a Discourse instance to make sure that the installed themes/components are compatible with the new Discourse version being deployed, and if the tests fail you can abort the build/deploy process so you don't end up with a broken site.
2021-04-26 12:56:45 +03:00
Osama Sayegh cd24eff5d9
FEATURE: Introduce theme/component QUnit tests (take 2) (#12661)
This commit allows themes and theme components to have QUnit tests. To add tests to your theme/component, create a top-level directory in your theme and name it `test`, and Discourse will save all the files in that directory (and its sub-directories) as "tests files" in the database. While tests files/directories are not required to be organized in a specific way, we recommend that you follow Discourse core's tests [structure](https://github.com/discourse/discourse/tree/master/app/assets/javascripts/discourse/tests).

Writing theme tests should be identical to writing plugins or core tests; all the `import` statements and APIs that you see in core (or plugins) to define/setup tests should just work in themes.

You do need a working Discourse install to run theme tests, and you have 2 ways to run theme tests:

* In the browser at the `/qunit` route. `/qunit` will run tests of all active themes/components as well as core and plugins. The `/qunit` now accepts a `theme_name` or `theme_url` params that you can use to run tests of a specific theme/component like so: `/qunit?theme_name=<your_theme_name>`.

* In the command line using the `themes:qunit` rake task. This take is meant to run tests of a single theme/component so you need to provide it with a theme name or URL like so: `bundle exec rake themes:qunit[name=<theme_name>]` or `bundle exec rake themes:qunit[url=<theme_url>]`.

There are some refactors to how Discourse processes JavaScript that comes with themes/components, and these refactors may break your JS customizations; see https://meta.discourse.org/t/upcoming-core-changes-that-may-break-some-themes-components-april-12/186252?u=osama for details on how you can check if your themes/components are affected and what you need to do to fix them.

This commit also improves theme error handling in Discourse. We will now be able to catch errors that occur when theme initializers are run and prevent them from breaking the site and other themes/components.
2021-04-12 15:02:58 +03:00
Osama Sayegh 2b9ab3a0d9
Revert "FEATURE: Introduce theme/component QUnit tests (#12517)" (#12632)
This reverts commit a53d8d3e61 and 105634435f.

Reverted because the change broke some components. Will be added back in a few days.
2021-04-07 17:45:49 +03:00
Osama Sayegh a53d8d3e61
FEATURE: Introduce theme/component QUnit tests (#12517)
This commit allows themes and theme components to have QUnit tests. To add tests to your theme/component, create a top-level directory in your theme and name it `test`, and Discourse will save all the files in that directory (and its sub-directories) as "tests files" in the database. While tests files/directories are not required to be organized in a specific way, we recommend that you follow Discourse core's tests [structure](https://github.com/discourse/discourse/tree/master/app/assets/javascripts/discourse/tests).

Writing theme tests should be identical to writing plugins or core tests; all the `import` statements and APIs that you see in core (or plugins) to define/setup tests should just work in themes.

You do need a working Discourse install to run theme tests, and you have 2 ways to run theme tests:

* In the browser at the `/qunit` route. `/qunit` will run tests of all active themes/components as well as core and plugins. The `/qunit` now accepts a `theme_name` or `theme_url` params that you can use to run tests of a specific theme/component like so: `/qunit?theme_name=<your_theme_name>`.

* In the command line using the `themes:qunit` rake task. This take is meant to run tests of a single theme/component so you need to provide it with a theme name or URL like so: `bundle exec rake themes:qunit[name=<theme_name>]` or `bundle exec rake themes:qunit[url=<theme_url>]`.

There are some refactors to internal code that's responsible for processing themes/components in Discourse, most notably:

* `<script type="text/discourse-plugin">` tags are automatically converted to modules.

* The `theme-settings` service is removed in favor of a simple `lib` file responsible for managing theme settings. This was done to allow us to register/lookup theme settings very early in our Ember app lifecycle and because there was no reason for it to be an Ember service.

These refactors should 100% backward compatible and invisible to theme developers.
2021-04-07 10:39:57 +03:00
Jarek Radosz abe688beb3 DEV: Use discourse/discourse_test in CI workflows
Using our testing Docker image (`discourse/discourse_test:release`) allows us to drop "Update imagemagick" step which shaves ~10 minutes from all runs.
2021-02-11 15:24:15 +01:00
Penar Musaraj a1955b0542
Dev: --dev option does nothing in yarn (#12032) 2021-02-10 19:19:47 -05:00
Penar Musaraj caa58a4bd1
DEV: Retry when Net::HTTP throws EOFError (#10921)
Might fix an inconsistent issue when running tests in CI.
2020-10-14 11:55:26 -04:00
Sam Saffron e8328968bb
DEV: allow qunit:test to run concurrently
Previously we were fighting on pid file which makes it hard to run multiple
2020-08-05 16:57:12 +10:00
Sam Saffron 8a50ab45aa
DEV: use REPORT_REQUESTS=1 to find all requests
We can use this to profile our pretender and ensure nothing is superfluous
and nothing is missing
2020-04-02 16:01:49 +11:00
David Taylor c8d438cc63
DEV: Allow CSP to be enabled during QUnit tests (#8668)
The QUnit rake task starts a server in test mode. We need a tweak to allow dynamic CSP hostnames in test mode. This tweak is already present in development mode.

To allow CSP to work, the browser host/port must match what the server sees. Therefore we need to disable the enforce_hostname middleware in test mode. To keep rspec and production as similar as possible, we skip enforce_hostname using an environment variable.

Also move the qunit rake task to use unicorn, for consistency with development and production.
2020-01-07 12:22:58 +00:00
Blake Erickson b7b85f9ade
FEATURE: Turn csp on by default (#8665)
* turn csp on by default

* remove csp migration for new sites now that is is on by default

* Ensure CSP is off before starting qunit
2020-01-06 13:42:21 -07:00
Blake Erickson fc6b093dce FIX: Ensure CSP is off for qunit
If CSP is turned on qunit won't run at all, not even via the CLI, this
is causing the js tests to fail.

Follow up to: 3193b0f6e6
2020-01-03 18:43:19 -07:00
Joffrey JAFFEUX 9ce9d72e71
DEV: makes hidepassed default when running qunit (#7558)
Mostly useful when not running headless, but I endup doing it a lot when debugging, one less thing to check.
2019-05-16 14:37:01 +02:00
Joffrey JAFFEUX 4a9756ff3f
DEV: sets rack server to test env when using rake qunit:test (#7554) 2019-05-16 10:44:29 +02:00
Sam Saffron 30990006a9 DEV: enable frozen string literal on all files
This reduces chances of errors where consumers of strings mutate inputs
and reduces memory usage of the app.

Test suite passes now, but there may be some stuff left, so we will run
a few sites on a branch prior to merging
2019-05-13 09:31:32 +08:00
David Taylor 404acef6e3 DEV: Move `run-qunit.js` out of the vendor directory 2018-12-03 16:16:37 +00:00
Gerhard Schlager a024e5e9ac Retry on read timeouts while warming up for qunit tests 2018-05-15 21:26:59 +02:00
Gerhard Schlager ec3a2d2762 Stop retrying tests three times if qunit tests fail
Warming up the Rails server should be enough
2018-03-12 12:51:26 +01:00
Joffrey JAFFEUX cc819539b0
FIX: makes rake qunit:test task work on macOS 2018-01-10 14:51:08 +01:00
Guo Xiang Tan 6f89db4c24 Re-enable check for yarn when running qunit:test rake task. 2017-12-22 09:11:49 +08:00
Guo Xiang Tan aabac55edd Better ENV name for QUnit's seed. 2017-12-21 09:47:32 +08:00
Guo Xiang Tan ca8e4dfb43 Allow seed to be passed via ENV. 2017-12-19 21:35:51 +08:00
Guo Xiang Tan 141a4a059d QUnit tests should be run in random order. 2017-12-19 21:33:31 +08:00
Guo Xiang Tan 349dc8da29 Disable check for yarn in qunit tests first. 2017-12-19 20:09:36 +08:00
Guo Xiang Tan 6a4f391e38 Switch to chrome headless mode instead of phantomjs. 2017-12-19 16:00:43 +08:00
David Taylor d65570a8a1 Preparation for using chrome for qunit in docker images (#5062)
Move use_chrome option to ENV variable
Rewrite script to work with node 6 (current LTS version used in discourse_docker)
Add node stuff to gitignore
2017-08-18 14:08:58 -04:00
David Taylor c981edfa20 Add option to run qunit tests in headless chrome (#5054) 2017-08-16 07:42:42 -04:00
Guo Xiang Tan 5012d46cbd Add rubocop to our build. (#5004) 2017-07-28 10:20:09 +09:00
Robin Ward 5cfc2d8972 Run wizard specs in docker:test 2017-07-27 11:29:18 -04:00
David Taylor febd7621ea Qunit plugin rake tasks (#4985)
* Allow running specific plugin tests using ENV variables

* Add a `rake plugin:qunit` task to match the existing `rake plugin:spec` task

* Improve docker.rake to allow running specific plugin qunit tests

* Purge cache before and after qunit tests

* Stop module auto-loader trying to auto-load tests

* Use URL query parameters to pass config into Qunit, avoiding caching issues

* Oops, searchParams doesn’t work in phantomJS. Parse the URL manually.

* Escape ampersands before passing URL to phantomJS, otherwise multiple parameters go wrong
2017-07-26 09:07:46 -04:00