discourse/lib/tasks/themes.rake

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

295 lines
9.4 KiB
Ruby
Raw Permalink Normal View History

# frozen_string_literal: true
require "yaml"
#
# 2 different formats are accepted:
#
# == JSON format
#
# bin/rake themes:install -- '--{"discourse-something": "https://github.com/discourse/discourse-something"}'
# OR
# bin/rake themes:install -- '--{"discourse-something": {"url": "https://github.com/discourse/discourse-something", default: true}}'
#
# == YAML file formats
#
# theme_name: https://github.com/example/theme.git
# OR
# theme_name:
# url: https://github.com/example/theme_name.git
# branch: "master"
# private_key: ""
# default: false
# add_to_all_themes: false # only for components - install on every theme
#
# In the first form, only the url is required.
#
desc "Install themes & theme components"
task "themes:install" => :environment do |task, args|
theme_args = (STDIN.tty?) ? "" : STDIN.read
use_json = theme_args == ""
theme_args =
begin
2021-10-27 04:39:28 -04:00
use_json ? JSON.parse(ARGV.last.gsub("--", "")) : YAML.safe_load(theme_args)
rescue StandardError
puts use_json ? "Invalid JSON input. \n#{ARGV.last}" : "Invalid YML: \n#{theme_args}"
exit 1
end
log, counts = ThemesInstallTask.install(theme_args)
puts log
puts
puts "Results:"
puts " Installed: #{counts[:installed]}"
puts " Updated: #{counts[:updated]}"
puts " Errors: #{counts[:errors]}"
puts " Skipped: #{counts[:skipped]}"
exit 1 if counts[:errors] > 0
end
# env THEME_ARCHIVE - path to the archive
# env UPDATE_COMPONENTS - 0 to skip updating components
desc "Install themes & theme components from an archive"
task "themes:install:archive" => :environment do |task, args|
filename = ENV["THEME_ARCHIVE"]
update_components = ENV["UPDATE_COMPONENTS"] == "0" ? "none" : nil
RemoteTheme.update_zipped_theme(filename, File.basename(filename), update_components:)
end
def update_themes(version_cache: Concurrent::Map.new)
Theme
.includes(:remote_theme)
.where(enabled: true, auto_update: true)
.find_each do |theme|
begin
theme.transaction do
remote_theme = theme.remote_theme
next if remote_theme.blank? || remote_theme.remote_url.blank?
prefix = "[db:#{RailsMultisite::ConnectionManagement.current_db}] '#{theme.name}' - "
puts "#{prefix} checking..."
cache_key =
"#{remote_theme.remote_url}:#{remote_theme.branch}:#{Digest::SHA256.hexdigest(remote_theme.private_key.to_s)}"
if version_cache[cache_key] == remote_theme.remote_version && !remote_theme.out_of_date?
puts "#{prefix} up to date (cached from previous lookup)"
next
end
remote_theme.update_remote_version
version_cache.put_if_absent(cache_key, remote_theme.remote_version)
if remote_theme.out_of_date?
puts "#{prefix} updating from #{remote_theme.local_version[0..7]} to #{remote_theme.remote_version[0..7]}"
remote_theme.update_from_remote(already_in_transaction: true)
else
puts "#{prefix} up to date"
end
if remote_theme.last_error_text.present?
raise RemoteTheme::ImportError.new(remote_theme.last_error_text)
end
end
rescue => e
$stderr.puts "[#{RailsMultisite::ConnectionManagement.current_db}] Failed to update '#{theme.name}' (#{theme.id}): #{e}"
raise if ENV["RAISE_THEME_ERRORS"] == "1"
end
end
true
end
desc "Update themes & theme components"
task "themes:update": %w[environment assets:precompile:theme_transpiler] do
if ENV["RAILS_DB"].present?
update_themes
else
version_cache = Concurrent::Map.new
concurrency = ENV["THEME_UPDATE_CONCURRENCY"]&.to_i || 10
puts "Updating themes with concurrency: #{concurrency}" if concurrency > 1
Parallel.each(RailsMultisite::ConnectionManagement.all_dbs, in_threads: concurrency) do |db|
RailsMultisite::ConnectionManagement.with_connection(db) { update_themes(version_cache:) }
end
end
end
desc "List all the installed themes on the site"
task "themes:audit" => :environment do
components = Set.new
puts "Selectable themes"
puts "-----------------"
Theme
.where("(enabled OR user_selectable) AND NOT component")
.each do |theme|
puts theme.remote_theme&.remote_url || theme.name
theme.child_themes.each do |child|
if child.enabled
repo = child.remote_theme&.remote_url || child.name
components << repo
end
end
end
puts
puts "Selectable components"
puts "---------------------"
components.each { |repo| puts repo }
end
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 08:02:58 -04:00
desc "Run QUnit tests of a theme/component"
task "themes:qunit", :type, :value do |t, args|
type = args[:type]
value = args[:value]
DEV: Run QUnit tests for official Discourse themes (#24405) Why this change? As the number of themes which the Discourse team supports officially grows, we want to ensure that changes made to Discourse core do not break the plugins. As such, we are adding a step to our Github actions test job to run the QUnit tests for all official themes. What does this change do? This change adds a new job to our tests Github actions workflow to run the QUnit tests for all official plugins. This is achieved with the following changes: 1. Update `testem.js` to rely on the `THEME_TEST_PAGES` env variable to set the `test_page` option when running theme QUnit tests with testem. The `test_page` option [allows an array to be specified](https://github.com/testem/testem#multiple-test-pages) such that tests for multiple pages can be run at the same time. We are relying on a ENV variable because the `testem` CLI does not support passing a list of pages to the `--test_page` option. 2. Support a `/testem-theme-qunit/:testem_id/theme-qunit` Rails route in the development environment. This is done because testem prefixes the path with a unique ID to the configured `test_page` URL. This is problematic for us because we proxy all testem requests to the Rails server and testem's proxy configuration option does not allow us to easily rewrite the URL to remove the prefix. Therefore, we configure a proxy in testem to prefix `theme-qunit` requests with `/testem-theme-qunit` which can then be easily identified by the Rails server and routed accordingly. 3. Update `qunit:test` to support a `THEME_IDS` environment variable which will allow it to run QUnit tests for multiple themes at the same time. 4. Support `bin/rake themes:qunit[ids,"<theme_id>|<theme_id>"]` to run the QUnit tests for multiple themes at the same time. 5. Adds a `themes:qunit_all_official` Rake task which runs the QUnit tests for all the official themes.
2023-11-16 18:17:32 -05:00
raise <<~TEXT if !%w[name url id ids].include?(type) || value.blank?
Wrong arguments type:#{type.inspect}, value:#{value.inspect}"
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 08:02:58 -04:00
Usage:
`bundle exec rake "themes:qunit[url,<theme_url>]"`
OR
`bundle exec rake "themes:qunit[name,<theme_name>]"`
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 08:02:58 -04:00
OR
`bundle exec rake "themes:qunit[id,<theme_id>]"`
DEV: Run QUnit tests for official Discourse themes (#24405) Why this change? As the number of themes which the Discourse team supports officially grows, we want to ensure that changes made to Discourse core do not break the plugins. As such, we are adding a step to our Github actions test job to run the QUnit tests for all official themes. What does this change do? This change adds a new job to our tests Github actions workflow to run the QUnit tests for all official plugins. This is achieved with the following changes: 1. Update `testem.js` to rely on the `THEME_TEST_PAGES` env variable to set the `test_page` option when running theme QUnit tests with testem. The `test_page` option [allows an array to be specified](https://github.com/testem/testem#multiple-test-pages) such that tests for multiple pages can be run at the same time. We are relying on a ENV variable because the `testem` CLI does not support passing a list of pages to the `--test_page` option. 2. Support a `/testem-theme-qunit/:testem_id/theme-qunit` Rails route in the development environment. This is done because testem prefixes the path with a unique ID to the configured `test_page` URL. This is problematic for us because we proxy all testem requests to the Rails server and testem's proxy configuration option does not allow us to easily rewrite the URL to remove the prefix. Therefore, we configure a proxy in testem to prefix `theme-qunit` requests with `/testem-theme-qunit` which can then be easily identified by the Rails server and routed accordingly. 3. Update `qunit:test` to support a `THEME_IDS` environment variable which will allow it to run QUnit tests for multiple themes at the same time. 4. Support `bin/rake themes:qunit[ids,"<theme_id>|<theme_id>"]` to run the QUnit tests for multiple themes at the same time. 5. Adds a `themes:qunit_all_official` Rake task which runs the QUnit tests for all the official themes.
2023-11-16 18:17:32 -05:00
OR
`bundle exec rake "themes:qunit[ids,<theme_id|theme_id|theme_id>]
TEXT
DEV: Run QUnit tests for official Discourse themes (#24405) Why this change? As the number of themes which the Discourse team supports officially grows, we want to ensure that changes made to Discourse core do not break the plugins. As such, we are adding a step to our Github actions test job to run the QUnit tests for all official themes. What does this change do? This change adds a new job to our tests Github actions workflow to run the QUnit tests for all official plugins. This is achieved with the following changes: 1. Update `testem.js` to rely on the `THEME_TEST_PAGES` env variable to set the `test_page` option when running theme QUnit tests with testem. The `test_page` option [allows an array to be specified](https://github.com/testem/testem#multiple-test-pages) such that tests for multiple pages can be run at the same time. We are relying on a ENV variable because the `testem` CLI does not support passing a list of pages to the `--test_page` option. 2. Support a `/testem-theme-qunit/:testem_id/theme-qunit` Rails route in the development environment. This is done because testem prefixes the path with a unique ID to the configured `test_page` URL. This is problematic for us because we proxy all testem requests to the Rails server and testem's proxy configuration option does not allow us to easily rewrite the URL to remove the prefix. Therefore, we configure a proxy in testem to prefix `theme-qunit` requests with `/testem-theme-qunit` which can then be easily identified by the Rails server and routed accordingly. 3. Update `qunit:test` to support a `THEME_IDS` environment variable which will allow it to run QUnit tests for multiple themes at the same time. 4. Support `bin/rake themes:qunit[ids,"<theme_id>|<theme_id>"]` to run the QUnit tests for multiple themes at the same time. 5. Adds a `themes:qunit_all_official` Rake task which runs the QUnit tests for all the official themes.
2023-11-16 18:17:32 -05:00
ENV["THEME_#{type.upcase}"] = value.to_s
ENV["QUNIT_RAILS_ENV"] ||= "development" # qunit:test will switch to `test` by default
Rake::Task["qunit:test"].reenable
Rake::Task["qunit:test"].invoke("/theme-qunit")
end
desc "Install a theme/component on a temporary DB and run QUnit tests"
task "themes:isolated_test" => :environment do |t, args|
# This task can be called in a production environment that likely has a bunch
# of DISCOURSE_* env vars that we don't want to be picked up by the Unicorn
# server that will be spawned for the tests. So we need to unset them all
# before we proceed.
# Make this behavior opt-in to make it very obvious.
if ENV["UNSET_DISCOURSE_ENV_VARS"] == "1"
ENV.keys.each do |key|
next if !key.start_with?("DISCOURSE_")
next if ENV["DONT_UNSET_#{key}"] == "1"
ENV[key] = nil
end
end
redis = TemporaryRedis.new
redis.start
Discourse.redis = redis.instance
db = TemporaryDb.new
db.start
db.migrate
ActiveRecord::Base.establish_connection(
adapter: "postgresql",
database: "discourse",
port: db.pg_port,
host: "localhost",
)
seeded_themes = Theme.pluck(:id)
Rake::Task["themes:install"].invoke
themes = Theme.pluck(:name, :id)
ENV["PGPORT"] = db.pg_port.to_s
ENV["PGHOST"] = "localhost"
ENV["QUNIT_RAILS_ENV"] = "development"
ENV["DISCOURSE_DEV_DB"] = "discourse"
ENV["DISCOURSE_REDIS_PORT"] = redis.port.to_s
count = 0
themes.each do |(name, id)|
if seeded_themes.include?(id)
puts "Skipping seeded theme #{name} (id: #{id})"
next
end
puts "Running tests for theme #{name} (id: #{id})..."
Rake::Task["themes:qunit"].reenable
Rake::Task["themes:qunit"].invoke("id", id)
count += 1
end
raise "Error: No themes were installed" if count == 0
ensure
db&.stop
db&.remove
redis&.remove
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 08:02:58 -04:00
end
DEV: Run QUnit tests for official Discourse themes (#24405) Why this change? As the number of themes which the Discourse team supports officially grows, we want to ensure that changes made to Discourse core do not break the plugins. As such, we are adding a step to our Github actions test job to run the QUnit tests for all official themes. What does this change do? This change adds a new job to our tests Github actions workflow to run the QUnit tests for all official plugins. This is achieved with the following changes: 1. Update `testem.js` to rely on the `THEME_TEST_PAGES` env variable to set the `test_page` option when running theme QUnit tests with testem. The `test_page` option [allows an array to be specified](https://github.com/testem/testem#multiple-test-pages) such that tests for multiple pages can be run at the same time. We are relying on a ENV variable because the `testem` CLI does not support passing a list of pages to the `--test_page` option. 2. Support a `/testem-theme-qunit/:testem_id/theme-qunit` Rails route in the development environment. This is done because testem prefixes the path with a unique ID to the configured `test_page` URL. This is problematic for us because we proxy all testem requests to the Rails server and testem's proxy configuration option does not allow us to easily rewrite the URL to remove the prefix. Therefore, we configure a proxy in testem to prefix `theme-qunit` requests with `/testem-theme-qunit` which can then be easily identified by the Rails server and routed accordingly. 3. Update `qunit:test` to support a `THEME_IDS` environment variable which will allow it to run QUnit tests for multiple themes at the same time. 4. Support `bin/rake themes:qunit[ids,"<theme_id>|<theme_id>"]` to run the QUnit tests for multiple themes at the same time. 5. Adds a `themes:qunit_all_official` Rake task which runs the QUnit tests for all the official themes.
2023-11-16 18:17:32 -05:00
desc "Clones all official themes"
task "themes:clone_all_official" do |task, args|
require "theme_metadata"
FileUtils.rm_rf("tmp/themes")
official_themes =
ThemeMetadata::OFFICIAL_THEMES.each do |theme_name|
repo = "https://github.com/discourse/#{theme_name}"
DEV: Run QUnit tests for official Discourse themes (#24405) Why this change? As the number of themes which the Discourse team supports officially grows, we want to ensure that changes made to Discourse core do not break the plugins. As such, we are adding a step to our Github actions test job to run the QUnit tests for all official themes. What does this change do? This change adds a new job to our tests Github actions workflow to run the QUnit tests for all official plugins. This is achieved with the following changes: 1. Update `testem.js` to rely on the `THEME_TEST_PAGES` env variable to set the `test_page` option when running theme QUnit tests with testem. The `test_page` option [allows an array to be specified](https://github.com/testem/testem#multiple-test-pages) such that tests for multiple pages can be run at the same time. We are relying on a ENV variable because the `testem` CLI does not support passing a list of pages to the `--test_page` option. 2. Support a `/testem-theme-qunit/:testem_id/theme-qunit` Rails route in the development environment. This is done because testem prefixes the path with a unique ID to the configured `test_page` URL. This is problematic for us because we proxy all testem requests to the Rails server and testem's proxy configuration option does not allow us to easily rewrite the URL to remove the prefix. Therefore, we configure a proxy in testem to prefix `theme-qunit` requests with `/testem-theme-qunit` which can then be easily identified by the Rails server and routed accordingly. 3. Update `qunit:test` to support a `THEME_IDS` environment variable which will allow it to run QUnit tests for multiple themes at the same time. 4. Support `bin/rake themes:qunit[ids,"<theme_id>|<theme_id>"]` to run the QUnit tests for multiple themes at the same time. 5. Adds a `themes:qunit_all_official` Rake task which runs the QUnit tests for all the official themes.
2023-11-16 18:17:32 -05:00
path = File.join(Rails.root, "tmp/themes/#{theme_name}")
attempts = 0
begin
attempts += 1
system("git clone #{repo} #{path}", exception: true)
rescue StandardError
abort("Failed to clone #{repo}") if attempts >= 3
STDERR.puts "Failed to clone #{repo}... trying again..."
retry
end
end
end
DEV: Run QUnit tests for official Discourse themes (#24405) Why this change? As the number of themes which the Discourse team supports officially grows, we want to ensure that changes made to Discourse core do not break the plugins. As such, we are adding a step to our Github actions test job to run the QUnit tests for all official themes. What does this change do? This change adds a new job to our tests Github actions workflow to run the QUnit tests for all official plugins. This is achieved with the following changes: 1. Update `testem.js` to rely on the `THEME_TEST_PAGES` env variable to set the `test_page` option when running theme QUnit tests with testem. The `test_page` option [allows an array to be specified](https://github.com/testem/testem#multiple-test-pages) such that tests for multiple pages can be run at the same time. We are relying on a ENV variable because the `testem` CLI does not support passing a list of pages to the `--test_page` option. 2. Support a `/testem-theme-qunit/:testem_id/theme-qunit` Rails route in the development environment. This is done because testem prefixes the path with a unique ID to the configured `test_page` URL. This is problematic for us because we proxy all testem requests to the Rails server and testem's proxy configuration option does not allow us to easily rewrite the URL to remove the prefix. Therefore, we configure a proxy in testem to prefix `theme-qunit` requests with `/testem-theme-qunit` which can then be easily identified by the Rails server and routed accordingly. 3. Update `qunit:test` to support a `THEME_IDS` environment variable which will allow it to run QUnit tests for multiple themes at the same time. 4. Support `bin/rake themes:qunit[ids,"<theme_id>|<theme_id>"]` to run the QUnit tests for multiple themes at the same time. 5. Adds a `themes:qunit_all_official` Rake task which runs the QUnit tests for all the official themes.
2023-11-16 18:17:32 -05:00
desc "pull compatible theme versions for all themes"
task "themes:pull_compatible_all" do |t|
Dir
.glob(File.expand_path("#{Rails.root}/tmp/themes/*"))
.select { |f| File.directory? f }
.each do |theme_path|
next unless File.directory?(theme_path + "/.git")
theme_name = File.basename(theme_path)
checkout_version = Discourse.find_compatible_git_resource(theme_path)
# Checkout value of the version compat
if checkout_version
puts "checking out compatible #{theme_name} version: #{checkout_version}"
update_status =
system(
"git -C '#{theme_path}' cat-file -e #{checkout_version} || git -C '#{theme_path}' fetch --depth 1 $(git -C '#{theme_path}' rev-parse --symbolic-full-name @{upstream} | awk -F '/' '{print $3}') #{checkout_version}; git -C '#{theme_path}' reset --hard #{checkout_version}",
)
abort("Unable to checkout a compatible theme version") unless update_status
else
puts "#{theme_name} is already at latest compatible version"
end
end
end
DEV: Run QUnit tests for official Discourse themes (#24405) Why this change? As the number of themes which the Discourse team supports officially grows, we want to ensure that changes made to Discourse core do not break the plugins. As such, we are adding a step to our Github actions test job to run the QUnit tests for all official themes. What does this change do? This change adds a new job to our tests Github actions workflow to run the QUnit tests for all official plugins. This is achieved with the following changes: 1. Update `testem.js` to rely on the `THEME_TEST_PAGES` env variable to set the `test_page` option when running theme QUnit tests with testem. The `test_page` option [allows an array to be specified](https://github.com/testem/testem#multiple-test-pages) such that tests for multiple pages can be run at the same time. We are relying on a ENV variable because the `testem` CLI does not support passing a list of pages to the `--test_page` option. 2. Support a `/testem-theme-qunit/:testem_id/theme-qunit` Rails route in the development environment. This is done because testem prefixes the path with a unique ID to the configured `test_page` URL. This is problematic for us because we proxy all testem requests to the Rails server and testem's proxy configuration option does not allow us to easily rewrite the URL to remove the prefix. Therefore, we configure a proxy in testem to prefix `theme-qunit` requests with `/testem-theme-qunit` which can then be easily identified by the Rails server and routed accordingly. 3. Update `qunit:test` to support a `THEME_IDS` environment variable which will allow it to run QUnit tests for multiple themes at the same time. 4. Support `bin/rake themes:qunit[ids,"<theme_id>|<theme_id>"]` to run the QUnit tests for multiple themes at the same time. 5. Adds a `themes:qunit_all_official` Rake task which runs the QUnit tests for all the official themes.
2023-11-16 18:17:32 -05:00
# Note that this should only be used in CI where it is safe to mutate the database without rolling back since running
# the themes QUnit tests requires the themes to be installed in the database.
desc "Runs qunit tests for all official themes"
task "themes:qunit_all_official" => :environment do |task, args|
DEV: Run QUnit tests for official Discourse themes (#24405) Why this change? As the number of themes which the Discourse team supports officially grows, we want to ensure that changes made to Discourse core do not break the plugins. As such, we are adding a step to our Github actions test job to run the QUnit tests for all official themes. What does this change do? This change adds a new job to our tests Github actions workflow to run the QUnit tests for all official plugins. This is achieved with the following changes: 1. Update `testem.js` to rely on the `THEME_TEST_PAGES` env variable to set the `test_page` option when running theme QUnit tests with testem. The `test_page` option [allows an array to be specified](https://github.com/testem/testem#multiple-test-pages) such that tests for multiple pages can be run at the same time. We are relying on a ENV variable because the `testem` CLI does not support passing a list of pages to the `--test_page` option. 2. Support a `/testem-theme-qunit/:testem_id/theme-qunit` Rails route in the development environment. This is done because testem prefixes the path with a unique ID to the configured `test_page` URL. This is problematic for us because we proxy all testem requests to the Rails server and testem's proxy configuration option does not allow us to easily rewrite the URL to remove the prefix. Therefore, we configure a proxy in testem to prefix `theme-qunit` requests with `/testem-theme-qunit` which can then be easily identified by the Rails server and routed accordingly. 3. Update `qunit:test` to support a `THEME_IDS` environment variable which will allow it to run QUnit tests for multiple themes at the same time. 4. Support `bin/rake themes:qunit[ids,"<theme_id>|<theme_id>"]` to run the QUnit tests for multiple themes at the same time. 5. Adds a `themes:qunit_all_official` Rake task which runs the QUnit tests for all the official themes.
2023-11-16 18:17:32 -05:00
theme_ids_with_qunit_tests = []
ThemeMetadata::OFFICIAL_THEMES.each do |theme_name|
path = File.join(Rails.root, "tmp/themes/#{theme_name}")
if Dir.glob("#{File.join(path, "test")}/**/*.{js,es6}").any?
theme = RemoteTheme.import_theme_from_directory(path)
theme_ids_with_qunit_tests << theme.id
else
puts "Skipping #{theme_name} as no QUnit tests have been detected"
end
end
Rake::Task["themes:qunit"].reenable
Rake::Task["themes:qunit"].invoke("ids", theme_ids_with_qunit_tests.join("|"))
end