discourse/Gemfile.lock

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

660 lines
15 KiB
Plaintext
Raw Normal View History

GIT
remote: https://github.com/discourse/mail.git
revision: 5b700fc95ee66378e0cf2559abc73c8bc3062a4b
specs:
mail (2.8.0.edge)
mini_mime (>= 0.1.1)
2013-02-05 14:16:51 -05:00
GEM
remote: https://rubygems.org/
2013-02-05 14:16:51 -05:00
specs:
actionmailer (7.0.3.1)
actionpack (= 7.0.3.1)
actionview (= 7.0.3.1)
activejob (= 7.0.3.1)
activesupport (= 7.0.3.1)
2014-09-24 20:28:27 -04:00
mail (~> 2.5, >= 2.5.4)
net-imap
net-pop
net-smtp
2017-08-22 22:58:25 -04:00
rails-dom-testing (~> 2.0)
actionpack (7.0.3.1)
actionview (= 7.0.3.1)
activesupport (= 7.0.3.1)
rack (~> 2.0, >= 2.2.0)
2017-10-03 02:56:44 -04:00
rack-test (>= 0.6.3)
2017-08-22 22:58:25 -04:00
rails-dom-testing (~> 2.0)
rails-html-sanitizer (~> 1.0, >= 1.2.0)
actionview (7.0.3.1)
activesupport (= 7.0.3.1)
2014-05-08 00:14:24 -04:00
builder (~> 3.1)
2017-08-22 22:58:25 -04:00
erubi (~> 1.4)
rails-dom-testing (~> 2.0)
rails-html-sanitizer (~> 1.1, >= 1.2.0)
actionview_precompiler (0.2.3)
actionview (>= 6.0.a)
active_model_serializers (0.8.4)
2013-07-23 14:42:52 -04:00
activemodel (>= 3.0)
activejob (7.0.3.1)
activesupport (= 7.0.3.1)
2017-08-22 22:58:25 -04:00
globalid (>= 0.3.6)
activemodel (7.0.3.1)
activesupport (= 7.0.3.1)
activerecord (7.0.3.1)
activemodel (= 7.0.3.1)
activesupport (= 7.0.3.1)
activesupport (7.0.3.1)
2017-08-22 22:58:25 -04:00
concurrent-ruby (~> 1.0, >= 1.0.2)
i18n (>= 1.6, < 2)
minitest (>= 5.1)
tzinfo (~> 2.0)
addressable (2.8.1)
public_suffix (>= 2.0.2, < 6.0)
annotate (3.2.0)
activerecord (>= 3.2, < 8.0)
rake (>= 10.4, < 14.0)
ast (2.4.2)
aws-eventstream (1.2.0)
aws-partitions (1.583.0)
aws-sdk-core (3.130.2)
aws-eventstream (~> 1, >= 1.0.2)
aws-partitions (~> 1, >= 1.525.0)
aws-sigv4 (~> 1.1)
2015-05-25 03:57:06 -04:00
jmespath (~> 1.0)
aws-sdk-kms (1.56.0)
aws-sdk-core (~> 3, >= 3.127.0)
aws-sigv4 (~> 1.1)
aws-sdk-s3 (1.114.0)
aws-sdk-core (~> 3, >= 3.127.0)
aws-sdk-kms (~> 1)
aws-sigv4 (~> 1.4)
aws-sdk-sns (1.53.0)
aws-sdk-core (~> 3, >= 3.127.0)
aws-sigv4 (~> 1.1)
aws-sigv4 (1.5.0)
aws-eventstream (~> 1, >= 1.0.2)
barber (0.12.2)
ember-source (>= 1.0, < 3.1)
execjs (>= 1.2, < 3)
better_errors (2.9.1)
2013-02-05 14:16:51 -05:00
coderay (>= 1.0.0)
erubi (>= 1.0.0)
2014-08-21 20:33:55 -04:00
rack (>= 0.9.0)
binding_of_caller (1.0.0)
2013-02-28 05:27:25 -05:00
debug_inspector (>= 0.0.1)
bootsnap (1.13.0)
msgpack (~> 1.2)
builder (3.2.4)
bullet (7.0.3)
2016-06-27 21:29:42 -04:00
activesupport (>= 3.0.0)
uniform_notifier (~> 1.11)
byebug (11.1.3)
capybara (3.38.0)
DEV: Minimal first pass of rails system test setup (#16311) This commit introduces rails system tests run with chromedriver, selenium, and headless chrome to our testing toolbox. We use the `webdrivers` gem and `selenium-webdriver` which is what the latest Rails uses so the tests run locally and in CI out of the box. You can use `SELENIUM_VERBOSE_DRIVER_LOGS=1` to show extra verbose logs of what selenium is doing to communicate with the system tests. By default JS logs are verbose so errors from JS are shown when running system tests, you can disable this with `SELENIUM_DISABLE_VERBOSE_JS_LOGS=1` You can use `SELENIUM_HEADLESS=0` to run the system tests inside a chrome browser instead of headless, which can be useful to debug things and see what the spec sees. See note above about `bin/ember-cli` to avoid surprises. I have modified `bin/turbo_rspec` to exclude `spec/system` by default, support for parallel system specs is a little shaky right now and we don't want them slowing down the turbo by default either. ### PageObjects and System Tests To make querying and inspecting parts of the page easier and more reusable inbetween system tests, we are using the concept of [PageObjects](https://www.selenium.dev/documentation/test_practices/encouraged/page_object_models/) in our system tests. A "Page" here is generally corresponds to an overarching ember route, e.g. "Topic" for `/t/324345/some-topic`, and this contains logic for querying components within the topic such as "Posts". I have also split "Modals" into their own entity. Further down the line we may want to explore creating independent "Component" contexts. Capybara DSL should be included in each PageObject class, reference for this can be found at https://rubydoc.info/github/teamcapybara/capybara/master#the-dsl For system tests, since they are so slow, we want to focus on the "happy path" and not do every different possible context and branch check using them. They are meant to be overarching tests that check a number of things are correct using the full stack from JS and ember to rails to ruby and then the database. ### CI Setup Whenever a system spec fails, a screenshot is taken and a build artifact is produced _after the entire CI run is complete_, which can be downloaded from the Actions UI in the repo. Most importantly, a step to build the Ember app using Ember CLI is needed, otherwise the JS assets cannot be found by capybara: ``` - name: Build Ember CLI run: bin/ember-cli --build ``` A new `--build` argument has been added to `bin/ember-cli` for this case, which is not needed locally if you already have the discourse rails server running via `bin/ember-cli -u` since the whole server is built and set up by default. Co-authored-by: David Taylor <david@taylorhq.com>
2022-09-27 21:48:16 -04:00
addressable
matrix
mini_mime (>= 0.1.3)
nokogiri (~> 1.8)
rack (>= 1.6.0)
rack-test (>= 0.6.3)
regexp_parser (>= 1.5, < 3.0)
xpath (~> 3.2)
cbor (0.5.9.6)
2014-09-24 20:40:35 -04:00
certified (1.0.0)
DEV: Minimal first pass of rails system test setup (#16311) This commit introduces rails system tests run with chromedriver, selenium, and headless chrome to our testing toolbox. We use the `webdrivers` gem and `selenium-webdriver` which is what the latest Rails uses so the tests run locally and in CI out of the box. You can use `SELENIUM_VERBOSE_DRIVER_LOGS=1` to show extra verbose logs of what selenium is doing to communicate with the system tests. By default JS logs are verbose so errors from JS are shown when running system tests, you can disable this with `SELENIUM_DISABLE_VERBOSE_JS_LOGS=1` You can use `SELENIUM_HEADLESS=0` to run the system tests inside a chrome browser instead of headless, which can be useful to debug things and see what the spec sees. See note above about `bin/ember-cli` to avoid surprises. I have modified `bin/turbo_rspec` to exclude `spec/system` by default, support for parallel system specs is a little shaky right now and we don't want them slowing down the turbo by default either. ### PageObjects and System Tests To make querying and inspecting parts of the page easier and more reusable inbetween system tests, we are using the concept of [PageObjects](https://www.selenium.dev/documentation/test_practices/encouraged/page_object_models/) in our system tests. A "Page" here is generally corresponds to an overarching ember route, e.g. "Topic" for `/t/324345/some-topic`, and this contains logic for querying components within the topic such as "Posts". I have also split "Modals" into their own entity. Further down the line we may want to explore creating independent "Component" contexts. Capybara DSL should be included in each PageObject class, reference for this can be found at https://rubydoc.info/github/teamcapybara/capybara/master#the-dsl For system tests, since they are so slow, we want to focus on the "happy path" and not do every different possible context and branch check using them. They are meant to be overarching tests that check a number of things are correct using the full stack from JS and ember to rails to ruby and then the database. ### CI Setup Whenever a system spec fails, a screenshot is taken and a build artifact is produced _after the entire CI run is complete_, which can be downloaded from the Actions UI in the repo. Most importantly, a step to build the Ember app using Ember CLI is needed, otherwise the JS assets cannot be found by capybara: ``` - name: Build Ember CLI run: bin/ember-cli --build ``` A new `--build` argument has been added to `bin/ember-cli` for this case, which is not needed locally if you already have the discourse rails server running via `bin/ember-cli -u` since the whole server is built and set up by default. Co-authored-by: David Taylor <david@taylorhq.com>
2022-09-27 21:48:16 -04:00
childprocess (4.1.0)
chunky_png (1.4.0)
coderay (1.1.3)
2018-07-24 10:12:15 -04:00
colored2 (3.1.2)
concurrent-ruby (1.1.10)
connection_pool (2.3.0)
cose (1.3.0)
cbor (~> 0.5.9)
openssl-signature_algorithm (~> 1.0)
cppjieba_rb (0.4.2)
crack (0.4.5)
rexml
crass (1.0.6)
css_parser (1.12.0)
addressable
debug_inspector (1.1.0)
diff-lcs (1.5.0)
diffy (3.4.2)
digest (3.1.0)
discourse-ember-rails (0.18.6)
active_model_serializers
ember-data-source (>= 1.0.0.beta.5)
ember-handlebars-template (>= 0.1.1, < 1.0)
ember-source (>= 1.1.0)
jquery-rails (>= 1.0.17)
railties (>= 3.1)
discourse-ember-source (3.12.2.3)
discourse-fonts (0.0.9)
discourse-seed-fu (2.3.12)
activerecord (>= 3.1)
activesupport (>= 3.1)
discourse_dev_assets (0.0.4)
faker (~> 2.16)
literate_randomizer
docile (1.4.0)
ecma-re-validator (0.4.0)
regexp_parser (~> 2.2)
email_reply_trimmer (0.1.13)
ember-data-source (3.0.2)
ember-source (>= 2, < 3.0)
ember-handlebars-template (0.8.0)
barber (>= 0.11.0)
sprockets (>= 3.3, < 4.1)
ember-source (2.18.2)
erubi (1.11.0)
excon (0.93.1)
execjs (2.8.1)
exifr (1.3.10)
fabrication (2.30.0)
faker (2.23.0)
i18n (>= 1.8.11, < 2)
fakeweb (1.3.0)
faraday (2.6.0)
faraday-net_http (>= 2.0, < 3.1)
ruby2_keywords (>= 0.0.4)
faraday-net_http (3.0.1)
faraday-retry (2.0.0)
faraday (~> 2.0)
fast_blank (1.0.1)
2013-02-05 14:16:51 -05:00
fast_xs (0.8.0)
fastimage (2.2.6)
ffi (1.15.5)
fspath (3.1.2)
gc_tracer (1.5.1)
globalid (1.0.0)
activesupport (>= 5.0)
2015-03-09 20:09:49 -04:00
guess_html_encoding (0.0.11)
hana (1.3.7)
hashdiff (1.0.1)
hashie (5.0.0)
highline (2.0.3)
hkdf (0.3.0)
2015-09-23 03:10:15 -04:00
htmlentities (4.3.4)
http_accept_language (2.1.1)
i18n (1.12.0)
concurrent-ruby (~> 1.0)
image_optim (0.31.1)
exifr (~> 1.2, >= 1.2.2)
fspath (~> 3.0)
image_size (>= 1.5, < 4)
in_threads (~> 1.3)
progress (~> 3.0, >= 3.0.1)
image_size (3.2.0)
in_threads (1.6.0)
jmespath (1.6.1)
jquery-rails (4.5.0)
2016-10-20 13:22:46 -04:00
rails-dom-testing (>= 1, < 3)
2015-12-26 01:02:42 -05:00
railties (>= 4.2.0)
thor (>= 0.14, < 2.0)
json (2.6.2)
json-schema (3.0.0)
addressable (>= 2.8)
json_schemer (0.2.23)
ecma-re-validator (~> 0.3)
hana (~> 1.3)
regexp_parser (~> 2.0)
uri_template (~> 0.7)
jwt (2.5.0)
kgio (2.11.4)
libv8-node (16.10.0.0)
2021-11-30 14:31:11 -05:00
libv8-node (16.10.0.0-aarch64-linux)
libv8-node (16.10.0.0-arm64-darwin)
libv8-node (16.10.0.0-x86_64-darwin)
libv8-node (16.10.0.0-x86_64-darwin-19)
libv8-node (16.10.0.0-x86_64-linux)
listen (3.7.1)
rb-fsevent (~> 0.10, >= 0.10.3)
rb-inotify (~> 0.9, >= 0.9.10)
literate_randomizer (0.4.0)
lograge (0.12.0)
actionpack (>= 4)
activesupport (>= 4)
railties (>= 4)
request_store (~> 1.0)
logstash-event (1.2.02)
logstash-logger (0.26.1)
logstash-event (~> 1.2)
logster (2.11.3)
loofah (2.19.0)
2017-10-03 02:56:44 -04:00
crass (~> 1.0.2)
2015-09-23 01:24:30 -04:00
nokogiri (>= 1.5.9)
lru_redux (1.1.0)
lz4-ruby (0.3.3)
DEV: Minimal first pass of rails system test setup (#16311) This commit introduces rails system tests run with chromedriver, selenium, and headless chrome to our testing toolbox. We use the `webdrivers` gem and `selenium-webdriver` which is what the latest Rails uses so the tests run locally and in CI out of the box. You can use `SELENIUM_VERBOSE_DRIVER_LOGS=1` to show extra verbose logs of what selenium is doing to communicate with the system tests. By default JS logs are verbose so errors from JS are shown when running system tests, you can disable this with `SELENIUM_DISABLE_VERBOSE_JS_LOGS=1` You can use `SELENIUM_HEADLESS=0` to run the system tests inside a chrome browser instead of headless, which can be useful to debug things and see what the spec sees. See note above about `bin/ember-cli` to avoid surprises. I have modified `bin/turbo_rspec` to exclude `spec/system` by default, support for parallel system specs is a little shaky right now and we don't want them slowing down the turbo by default either. ### PageObjects and System Tests To make querying and inspecting parts of the page easier and more reusable inbetween system tests, we are using the concept of [PageObjects](https://www.selenium.dev/documentation/test_practices/encouraged/page_object_models/) in our system tests. A "Page" here is generally corresponds to an overarching ember route, e.g. "Topic" for `/t/324345/some-topic`, and this contains logic for querying components within the topic such as "Posts". I have also split "Modals" into their own entity. Further down the line we may want to explore creating independent "Component" contexts. Capybara DSL should be included in each PageObject class, reference for this can be found at https://rubydoc.info/github/teamcapybara/capybara/master#the-dsl For system tests, since they are so slow, we want to focus on the "happy path" and not do every different possible context and branch check using them. They are meant to be overarching tests that check a number of things are correct using the full stack from JS and ember to rails to ruby and then the database. ### CI Setup Whenever a system spec fails, a screenshot is taken and a build artifact is produced _after the entire CI run is complete_, which can be downloaded from the Actions UI in the repo. Most importantly, a step to build the Ember app using Ember CLI is needed, otherwise the JS assets cannot be found by capybara: ``` - name: Build Ember CLI run: bin/ember-cli --build ``` A new `--build` argument has been added to `bin/ember-cli` for this case, which is not needed locally if you already have the discourse rails server running via `bin/ember-cli -u` since the whole server is built and set up by default. Co-authored-by: David Taylor <david@taylorhq.com>
2022-09-27 21:48:16 -04:00
matrix (0.4.2)
maxminddb (0.1.22)
memory_profiler (1.0.1)
message_bus (4.2.0)
rack (>= 1.1.3)
method_source (1.0.0)
mini_mime (1.1.2)
mini_portile2 (2.8.0)
mini_racer (0.6.3)
libv8-node (~> 16.10.0.0)
mini_scheduler (0.14.0)
sidekiq (>= 4.2.3)
mini_sql (1.4.0)
mini_suffix (0.3.3)
ffi (~> 1.9)
minitest (5.16.3)
mocha (2.0.1)
ruby2_keywords (>= 0.0.5)
msgpack (1.6.0)
multi_json (1.15.0)
2017-03-27 16:51:52 -04:00
multi_xml (0.6.0)
mustache (1.1.1)
net-http (0.2.2)
uri
net-imap (0.3.1)
net-protocol
net-pop (0.1.2)
net-protocol
net-protocol (0.1.3)
timeout
net-smtp (0.3.3)
net-protocol
nio4r (2.5.8)
nokogiri (1.13.9)
mini_portile2 (~> 2.8.0)
racc (~> 1.4)
nokogiri (1.13.9-aarch64-linux)
racc (~> 1.4)
nokogiri (1.13.9-arm64-darwin)
racc (~> 1.4)
nokogiri (1.13.9-x86_64-darwin)
racc (~> 1.4)
nokogiri (1.13.9-x86_64-linux)
racc (~> 1.4)
oauth (1.1.0)
oauth-tty (~> 1.0, >= 1.0.1)
snaky_hash (~> 2.0)
version_gem (~> 1.1)
oauth-tty (1.0.5)
version_gem (~> 1.1, >= 1.1.1)
oauth2 (1.4.11)
faraday (>= 0.17.3, < 3.0)
2018-12-31 14:07:18 -05:00
jwt (>= 1.0, < 3.0)
multi_json (~> 1.3)
multi_xml (~> 0.5)
rack (>= 1.2, < 4)
oj (3.13.14)
omniauth (1.9.2)
2020-03-16 09:12:10 -04:00
hashie (>= 3.4.6)
2017-03-27 16:51:52 -04:00
rack (>= 1.6.2, < 3)
omniauth-facebook (9.0.0)
2014-09-24 20:40:35 -04:00
omniauth-oauth2 (~> 1.2)
omniauth-github (1.4.0)
omniauth (~> 1.5)
omniauth-oauth2 (>= 1.4.0, < 2.0)
omniauth-google-oauth2 (0.8.2)
2018-12-31 14:07:18 -05:00
jwt (>= 2.0)
oauth2 (~> 1.1)
omniauth (~> 1.1)
omniauth-oauth2 (>= 1.6)
omniauth-oauth (1.2.0)
oauth
omniauth (>= 1.0, < 3)
omniauth-oauth2 (1.7.3)
oauth2 (>= 1.4, < 3)
omniauth (>= 1.9, < 3)
omniauth-twitter (1.4.0)
2015-09-23 03:18:43 -04:00
omniauth-oauth (~> 1.1)
rack
openssl (3.0.1)
openssl-signature_algorithm (1.2.1)
openssl (> 2.0, < 3.1)
optimist (3.0.1)
parallel (1.22.1)
parallel_tests (4.0.0)
parallel
parser (3.1.2.1)
ast (~> 2.4.1)
pg (1.4.4)
progress (3.6.0)
pry (0.14.1)
coderay (~> 1.1)
method_source (~> 1.0)
pry-byebug (3.10.1)
byebug (~> 11.0)
pry (>= 0.13, < 0.15)
pry-rails (0.3.9)
pry (>= 0.10.4)
public_suffix (5.0.0)
puma (5.6.5)
nio4r (~> 2.0)
r2 (0.2.7)
racc (1.6.0)
rack (2.2.4)
rack-mini-profiler (3.0.0)
rack (>= 1.2.0)
rack-protection (3.0.2)
2013-02-05 14:16:51 -05:00
rack
rack-test (2.0.2)
rack (>= 1.3)
2017-08-22 22:58:25 -04:00
rails-dom-testing (2.0.3)
activesupport (>= 4.2.0)
nokogiri (>= 1.6)
rails-html-sanitizer (1.4.3)
loofah (~> 2.3)
rails_failover (0.8.1)
activerecord (> 6.0, < 7.1)
concurrent-ruby
railties (> 6.0, < 7.1)
rails_multisite (4.0.1)
activerecord (> 5.0, < 7.1)
railties (> 5.0, < 7.1)
railties (7.0.3.1)
actionpack (= 7.0.3.1)
activesupport (= 7.0.3.1)
2017-08-22 22:58:25 -04:00
method_source
rake (>= 12.2)
thor (~> 1.0)
zeitwerk (~> 2.5)
rainbow (3.1.1)
raindrops (0.20.0)
rake (13.0.6)
rb-fsevent (0.11.2)
rb-inotify (0.10.1)
2019-03-20 12:04:26 -04:00
ffi (~> 1.0)
rbtrace (0.4.14)
ffi (>= 1.0.6)
msgpack (>= 0.4.3)
optimist (>= 3.0.0)
rchardet (1.8.0)
redis (4.7.1)
redis-namespace (1.9.0)
redis (>= 4)
regexp_parser (2.6.0)
request_store (1.5.1)
rack (>= 1.4)
rexml (3.2.5)
rinku (2.0.6)
rotp (6.2.0)
rqrcode (2.1.2)
chunky_png (~> 1.0)
rqrcode_core (~> 1.0)
rqrcode_core (1.2.0)
rspec (3.12.0)
rspec-core (~> 3.12.0)
rspec-expectations (~> 3.12.0)
rspec-mocks (~> 3.12.0)
rspec-core (3.12.0)
rspec-support (~> 3.12.0)
rspec-expectations (3.12.0)
2015-04-25 18:29:43 -04:00
diff-lcs (>= 1.2.0, < 2.0)
rspec-support (~> 3.12.0)
rspec-html-matchers (0.10.0)
nokogiri (~> 1)
rspec (>= 3.0.0.a)
rspec-mocks (3.12.0)
2015-04-25 18:29:43 -04:00
diff-lcs (>= 1.2.0, < 2.0)
rspec-support (~> 3.12.0)
rspec-rails (6.0.1)
actionpack (>= 6.1)
activesupport (>= 6.1)
railties (>= 6.1)
rspec-core (~> 3.11)
rspec-expectations (~> 3.11)
rspec-mocks (~> 3.11)
rspec-support (~> 3.11)
rspec-support (3.12.0)
rss (0.2.9)
rexml
rswag-specs (2.7.0)
activesupport (>= 3.1, < 7.1)
json-schema (>= 2.2, < 4.0)
railties (>= 3.1, < 7.1)
rspec-core (>= 2.14)
rubocop (1.38.0)
json (~> 2.3)
2017-07-31 21:51:44 -04:00
parallel (~> 1.10)
parser (>= 3.1.2.1)
rainbow (>= 2.2.2, < 4.0)
regexp_parser (>= 1.8, < 3.0)
rexml (>= 3.2.5, < 4.0)
2022-10-25 21:05:15 -04:00
rubocop-ast (>= 1.23.0, < 2.0)
2017-07-31 21:51:44 -04:00
ruby-progressbar (~> 1.7)
unicode-display_width (>= 1.4.0, < 3.0)
rubocop-ast (1.23.0)
parser (>= 3.1.1.0)
rubocop-discourse (3.0)
rubocop (>= 1.1.0)
rubocop-rspec (>= 2.0.0)
rubocop-rspec (2.15.0)
rubocop (~> 1.33)
ruby-prof (1.4.3)
ruby-progressbar (1.11.0)
2014-09-24 20:40:35 -04:00
ruby-readability (0.7.0)
2014-02-17 11:44:28 -05:00
guess_html_encoding (>= 0.0.4)
2014-09-24 20:40:35 -04:00
nokogiri (>= 1.6.0)
ruby2_keywords (0.0.5)
rubyzip (2.3.2)
sanitize (6.0.0)
2015-09-23 03:10:15 -04:00
crass (~> 1.0.2)
nokogiri (>= 1.12.0)
sassc (2.0.1)
2019-03-20 12:04:26 -04:00
ffi (~> 1.9)
rake
sassc-rails (2.1.2)
railties (>= 4.0.0)
sassc (>= 2.0)
sprockets (> 3.0)
sprockets-rails
tilt
selenium-webdriver (4.5.0)
DEV: Minimal first pass of rails system test setup (#16311) This commit introduces rails system tests run with chromedriver, selenium, and headless chrome to our testing toolbox. We use the `webdrivers` gem and `selenium-webdriver` which is what the latest Rails uses so the tests run locally and in CI out of the box. You can use `SELENIUM_VERBOSE_DRIVER_LOGS=1` to show extra verbose logs of what selenium is doing to communicate with the system tests. By default JS logs are verbose so errors from JS are shown when running system tests, you can disable this with `SELENIUM_DISABLE_VERBOSE_JS_LOGS=1` You can use `SELENIUM_HEADLESS=0` to run the system tests inside a chrome browser instead of headless, which can be useful to debug things and see what the spec sees. See note above about `bin/ember-cli` to avoid surprises. I have modified `bin/turbo_rspec` to exclude `spec/system` by default, support for parallel system specs is a little shaky right now and we don't want them slowing down the turbo by default either. ### PageObjects and System Tests To make querying and inspecting parts of the page easier and more reusable inbetween system tests, we are using the concept of [PageObjects](https://www.selenium.dev/documentation/test_practices/encouraged/page_object_models/) in our system tests. A "Page" here is generally corresponds to an overarching ember route, e.g. "Topic" for `/t/324345/some-topic`, and this contains logic for querying components within the topic such as "Posts". I have also split "Modals" into their own entity. Further down the line we may want to explore creating independent "Component" contexts. Capybara DSL should be included in each PageObject class, reference for this can be found at https://rubydoc.info/github/teamcapybara/capybara/master#the-dsl For system tests, since they are so slow, we want to focus on the "happy path" and not do every different possible context and branch check using them. They are meant to be overarching tests that check a number of things are correct using the full stack from JS and ember to rails to ruby and then the database. ### CI Setup Whenever a system spec fails, a screenshot is taken and a build artifact is produced _after the entire CI run is complete_, which can be downloaded from the Actions UI in the repo. Most importantly, a step to build the Ember app using Ember CLI is needed, otherwise the JS assets cannot be found by capybara: ``` - name: Build Ember CLI run: bin/ember-cli --build ``` A new `--build` argument has been added to `bin/ember-cli` for this case, which is not needed locally if you already have the discourse rails server running via `bin/ember-cli -u` since the whole server is built and set up by default. Co-authored-by: David Taylor <david@taylorhq.com>
2022-09-27 21:48:16 -04:00
childprocess (>= 0.5, < 5.0)
rexml (~> 3.2, >= 3.2.5)
rubyzip (>= 1.2.2, < 3.0)
websocket (~> 1.0)
shoulda-matchers (5.2.0)
activesupport (>= 5.2.0)
sidekiq (6.5.7)
connection_pool (>= 2.2.5)
rack (~> 2.0)
redis (>= 4.5.0, < 5)
simplecov (0.21.2)
docile (~> 1.1)
simplecov-html (~> 0.11)
simplecov_json_formatter (~> 0.1)
simplecov-html (0.12.3)
simplecov_json_formatter (0.1.4)
snaky_hash (2.0.1)
hashie
version_gem (~> 1.1, >= 1.1.1)
sprockets (3.7.2)
concurrent-ruby (~> 1.0)
rack (> 1, < 3)
sprockets-rails (3.4.2)
actionpack (>= 5.2)
activesupport (>= 5.2)
sprockets (>= 3.0.0)
sshkey (2.0.0)
stackprof (0.2.22)
test-prof (1.0.11)
thor (1.2.1)
tilt (2.0.11)
timeout (0.3.0)
tzinfo (2.0.5)
concurrent-ruby (~> 1.0)
uglifier (4.2.0)
2016-05-22 22:23:15 -04:00
execjs (>= 0.3.0, < 3)
2014-09-24 20:40:35 -04:00
unf (0.1.4)
unf_ext
unf_ext (0.0.8.2)
unicode-display_width (2.3.0)
unicorn (6.1.0)
kgio (~> 2.6)
raindrops (~> 0.7)
uniform_notifier (1.16.0)
uri (0.11.0)
uri_template (0.7.0)
version_gem (1.1.1)
webdrivers (5.2.0)
DEV: Minimal first pass of rails system test setup (#16311) This commit introduces rails system tests run with chromedriver, selenium, and headless chrome to our testing toolbox. We use the `webdrivers` gem and `selenium-webdriver` which is what the latest Rails uses so the tests run locally and in CI out of the box. You can use `SELENIUM_VERBOSE_DRIVER_LOGS=1` to show extra verbose logs of what selenium is doing to communicate with the system tests. By default JS logs are verbose so errors from JS are shown when running system tests, you can disable this with `SELENIUM_DISABLE_VERBOSE_JS_LOGS=1` You can use `SELENIUM_HEADLESS=0` to run the system tests inside a chrome browser instead of headless, which can be useful to debug things and see what the spec sees. See note above about `bin/ember-cli` to avoid surprises. I have modified `bin/turbo_rspec` to exclude `spec/system` by default, support for parallel system specs is a little shaky right now and we don't want them slowing down the turbo by default either. ### PageObjects and System Tests To make querying and inspecting parts of the page easier and more reusable inbetween system tests, we are using the concept of [PageObjects](https://www.selenium.dev/documentation/test_practices/encouraged/page_object_models/) in our system tests. A "Page" here is generally corresponds to an overarching ember route, e.g. "Topic" for `/t/324345/some-topic`, and this contains logic for querying components within the topic such as "Posts". I have also split "Modals" into their own entity. Further down the line we may want to explore creating independent "Component" contexts. Capybara DSL should be included in each PageObject class, reference for this can be found at https://rubydoc.info/github/teamcapybara/capybara/master#the-dsl For system tests, since they are so slow, we want to focus on the "happy path" and not do every different possible context and branch check using them. They are meant to be overarching tests that check a number of things are correct using the full stack from JS and ember to rails to ruby and then the database. ### CI Setup Whenever a system spec fails, a screenshot is taken and a build artifact is produced _after the entire CI run is complete_, which can be downloaded from the Actions UI in the repo. Most importantly, a step to build the Ember app using Ember CLI is needed, otherwise the JS assets cannot be found by capybara: ``` - name: Build Ember CLI run: bin/ember-cli --build ``` A new `--build` argument has been added to `bin/ember-cli` for this case, which is not needed locally if you already have the discourse rails server running via `bin/ember-cli -u` since the whole server is built and set up by default. Co-authored-by: David Taylor <david@taylorhq.com>
2022-09-27 21:48:16 -04:00
nokogiri (~> 1.6)
rubyzip (>= 1.3.0)
selenium-webdriver (~> 4.0)
webmock (3.18.1)
addressable (>= 2.8.0)
2017-04-15 00:11:02 -04:00
crack (>= 0.3.2)
hashdiff (>= 0.4.0, < 2.0.0)
webpush (1.1.0)
hkdf (~> 0.2)
jwt (~> 2.0)
DEV: Minimal first pass of rails system test setup (#16311) This commit introduces rails system tests run with chromedriver, selenium, and headless chrome to our testing toolbox. We use the `webdrivers` gem and `selenium-webdriver` which is what the latest Rails uses so the tests run locally and in CI out of the box. You can use `SELENIUM_VERBOSE_DRIVER_LOGS=1` to show extra verbose logs of what selenium is doing to communicate with the system tests. By default JS logs are verbose so errors from JS are shown when running system tests, you can disable this with `SELENIUM_DISABLE_VERBOSE_JS_LOGS=1` You can use `SELENIUM_HEADLESS=0` to run the system tests inside a chrome browser instead of headless, which can be useful to debug things and see what the spec sees. See note above about `bin/ember-cli` to avoid surprises. I have modified `bin/turbo_rspec` to exclude `spec/system` by default, support for parallel system specs is a little shaky right now and we don't want them slowing down the turbo by default either. ### PageObjects and System Tests To make querying and inspecting parts of the page easier and more reusable inbetween system tests, we are using the concept of [PageObjects](https://www.selenium.dev/documentation/test_practices/encouraged/page_object_models/) in our system tests. A "Page" here is generally corresponds to an overarching ember route, e.g. "Topic" for `/t/324345/some-topic`, and this contains logic for querying components within the topic such as "Posts". I have also split "Modals" into their own entity. Further down the line we may want to explore creating independent "Component" contexts. Capybara DSL should be included in each PageObject class, reference for this can be found at https://rubydoc.info/github/teamcapybara/capybara/master#the-dsl For system tests, since they are so slow, we want to focus on the "happy path" and not do every different possible context and branch check using them. They are meant to be overarching tests that check a number of things are correct using the full stack from JS and ember to rails to ruby and then the database. ### CI Setup Whenever a system spec fails, a screenshot is taken and a build artifact is produced _after the entire CI run is complete_, which can be downloaded from the Actions UI in the repo. Most importantly, a step to build the Ember app using Ember CLI is needed, otherwise the JS assets cannot be found by capybara: ``` - name: Build Ember CLI run: bin/ember-cli --build ``` A new `--build` argument has been added to `bin/ember-cli` for this case, which is not needed locally if you already have the discourse rails server running via `bin/ember-cli -u` since the whole server is built and set up by default. Co-authored-by: David Taylor <david@taylorhq.com>
2022-09-27 21:48:16 -04:00
websocket (1.2.9)
xorcist (1.1.3)
DEV: Minimal first pass of rails system test setup (#16311) This commit introduces rails system tests run with chromedriver, selenium, and headless chrome to our testing toolbox. We use the `webdrivers` gem and `selenium-webdriver` which is what the latest Rails uses so the tests run locally and in CI out of the box. You can use `SELENIUM_VERBOSE_DRIVER_LOGS=1` to show extra verbose logs of what selenium is doing to communicate with the system tests. By default JS logs are verbose so errors from JS are shown when running system tests, you can disable this with `SELENIUM_DISABLE_VERBOSE_JS_LOGS=1` You can use `SELENIUM_HEADLESS=0` to run the system tests inside a chrome browser instead of headless, which can be useful to debug things and see what the spec sees. See note above about `bin/ember-cli` to avoid surprises. I have modified `bin/turbo_rspec` to exclude `spec/system` by default, support for parallel system specs is a little shaky right now and we don't want them slowing down the turbo by default either. ### PageObjects and System Tests To make querying and inspecting parts of the page easier and more reusable inbetween system tests, we are using the concept of [PageObjects](https://www.selenium.dev/documentation/test_practices/encouraged/page_object_models/) in our system tests. A "Page" here is generally corresponds to an overarching ember route, e.g. "Topic" for `/t/324345/some-topic`, and this contains logic for querying components within the topic such as "Posts". I have also split "Modals" into their own entity. Further down the line we may want to explore creating independent "Component" contexts. Capybara DSL should be included in each PageObject class, reference for this can be found at https://rubydoc.info/github/teamcapybara/capybara/master#the-dsl For system tests, since they are so slow, we want to focus on the "happy path" and not do every different possible context and branch check using them. They are meant to be overarching tests that check a number of things are correct using the full stack from JS and ember to rails to ruby and then the database. ### CI Setup Whenever a system spec fails, a screenshot is taken and a build artifact is produced _after the entire CI run is complete_, which can be downloaded from the Actions UI in the repo. Most importantly, a step to build the Ember app using Ember CLI is needed, otherwise the JS assets cannot be found by capybara: ``` - name: Build Ember CLI run: bin/ember-cli --build ``` A new `--build` argument has been added to `bin/ember-cli` for this case, which is not needed locally if you already have the discourse rails server running via `bin/ember-cli -u` since the whole server is built and set up by default. Co-authored-by: David Taylor <david@taylorhq.com>
2022-09-27 21:48:16 -04:00
xpath (3.2.0)
nokogiri (~> 1.8)
yaml-lint (0.0.10)
zeitwerk (2.6.4)
2013-02-05 14:16:51 -05:00
PLATFORMS
2021-11-30 14:31:11 -05:00
aarch64-linux
arm64-darwin-20
2013-02-05 14:16:51 -05:00
ruby
x86_64-darwin-18
x86_64-darwin-19
x86_64-darwin-20
x86_64-linux
2013-02-05 14:16:51 -05:00
DEPENDENCIES
actionmailer (= 7.0.3.1)
actionpack (= 7.0.3.1)
actionview (= 7.0.3.1)
actionview_precompiler
active_model_serializers (~> 0.8.3)
activemodel (= 7.0.3.1)
activerecord (= 7.0.3.1)
activesupport (= 7.0.3.1)
addressable
annotate
aws-sdk-s3
aws-sdk-sns
2013-06-06 17:50:49 -04:00
barber
2013-02-05 14:16:51 -05:00
better_errors
binding_of_caller
2017-05-26 13:26:45 -04:00
bootsnap
2016-06-27 21:29:42 -04:00
bullet
2015-08-13 23:59:06 -04:00
byebug
DEV: Minimal first pass of rails system test setup (#16311) This commit introduces rails system tests run with chromedriver, selenium, and headless chrome to our testing toolbox. We use the `webdrivers` gem and `selenium-webdriver` which is what the latest Rails uses so the tests run locally and in CI out of the box. You can use `SELENIUM_VERBOSE_DRIVER_LOGS=1` to show extra verbose logs of what selenium is doing to communicate with the system tests. By default JS logs are verbose so errors from JS are shown when running system tests, you can disable this with `SELENIUM_DISABLE_VERBOSE_JS_LOGS=1` You can use `SELENIUM_HEADLESS=0` to run the system tests inside a chrome browser instead of headless, which can be useful to debug things and see what the spec sees. See note above about `bin/ember-cli` to avoid surprises. I have modified `bin/turbo_rspec` to exclude `spec/system` by default, support for parallel system specs is a little shaky right now and we don't want them slowing down the turbo by default either. ### PageObjects and System Tests To make querying and inspecting parts of the page easier and more reusable inbetween system tests, we are using the concept of [PageObjects](https://www.selenium.dev/documentation/test_practices/encouraged/page_object_models/) in our system tests. A "Page" here is generally corresponds to an overarching ember route, e.g. "Topic" for `/t/324345/some-topic`, and this contains logic for querying components within the topic such as "Posts". I have also split "Modals" into their own entity. Further down the line we may want to explore creating independent "Component" contexts. Capybara DSL should be included in each PageObject class, reference for this can be found at https://rubydoc.info/github/teamcapybara/capybara/master#the-dsl For system tests, since they are so slow, we want to focus on the "happy path" and not do every different possible context and branch check using them. They are meant to be overarching tests that check a number of things are correct using the full stack from JS and ember to rails to ruby and then the database. ### CI Setup Whenever a system spec fails, a screenshot is taken and a build artifact is produced _after the entire CI run is complete_, which can be downloaded from the Actions UI in the repo. Most importantly, a step to build the Ember app using Ember CLI is needed, otherwise the JS assets cannot be found by capybara: ``` - name: Build Ember CLI run: bin/ember-cli --build ``` A new `--build` argument has been added to `bin/ember-cli` for this case, which is not needed locally if you already have the discourse rails server running via `bin/ember-cli -u` since the whole server is built and set up by default. Co-authored-by: David Taylor <david@taylorhq.com>
2022-09-27 21:48:16 -04:00
capybara
cbor
2013-02-05 14:16:51 -05:00
certified
colored2
cose
cppjieba_rb
css_parser
diffy
digest
discourse-ember-rails (= 0.18.6)
discourse-ember-source (~> 3.12.2)
discourse-fonts
discourse-seed-fu
discourse_dev_assets
email_reply_trimmer
ember-handlebars-template (= 0.8.0)
2015-05-25 03:57:06 -04:00
excon
execjs
fabrication
faker (~> 2.16)
fakeweb
faraday
faraday-retry
fast_blank
2013-02-05 14:16:51 -05:00
fast_xs
fastimage
gc_tracer
highline
htmlentities
http_accept_language
image_optim
json
json_schemer
2017-04-13 10:26:07 -04:00
listen
lograge
logstash-event
logstash-logger
logster
loofah
2013-04-23 21:59:59 -04:00
lru_redux
lz4-ruby
mail!
maxminddb
memory_profiler
message_bus
mini_mime
mini_racer
mini_scheduler
mini_sql
mini_suffix
2013-02-23 18:24:28 -05:00
minitest
mocha
2013-02-05 14:16:51 -05:00
multi_json
mustache
net-http
net-imap
net-pop
net-smtp
2016-06-07 02:54:36 -04:00
nokogiri
oj (= 3.13.14)
omniauth
omniauth-facebook
omniauth-github
omniauth-google-oauth2
omniauth-oauth2
omniauth-twitter
parallel_tests
pg
pry-byebug
2013-02-05 14:16:51 -05:00
pry-rails
puma
r2
rack
2014-02-17 11:44:28 -05:00
rack-mini-profiler
rack-protection
rails_failover
2018-02-12 01:08:02 -05:00
rails_multisite
railties (= 7.0.3.1)
2013-02-05 14:16:51 -05:00
rake
rb-fsevent
rbtrace
rchardet
redis
2015-12-31 23:40:12 -05:00
redis-namespace
2013-02-05 14:16:51 -05:00
rinku
rotp
rqrcode
2016-05-29 23:38:04 -04:00
rspec
rspec-html-matchers
rspec-rails
rss
rswag-specs
rubocop-discourse
2017-09-05 02:55:20 -04:00
ruby-prof
ruby-readability
rubyzip
sanitize
sassc (= 2.0.1)
sassc-rails
DEV: Minimal first pass of rails system test setup (#16311) This commit introduces rails system tests run with chromedriver, selenium, and headless chrome to our testing toolbox. We use the `webdrivers` gem and `selenium-webdriver` which is what the latest Rails uses so the tests run locally and in CI out of the box. You can use `SELENIUM_VERBOSE_DRIVER_LOGS=1` to show extra verbose logs of what selenium is doing to communicate with the system tests. By default JS logs are verbose so errors from JS are shown when running system tests, you can disable this with `SELENIUM_DISABLE_VERBOSE_JS_LOGS=1` You can use `SELENIUM_HEADLESS=0` to run the system tests inside a chrome browser instead of headless, which can be useful to debug things and see what the spec sees. See note above about `bin/ember-cli` to avoid surprises. I have modified `bin/turbo_rspec` to exclude `spec/system` by default, support for parallel system specs is a little shaky right now and we don't want them slowing down the turbo by default either. ### PageObjects and System Tests To make querying and inspecting parts of the page easier and more reusable inbetween system tests, we are using the concept of [PageObjects](https://www.selenium.dev/documentation/test_practices/encouraged/page_object_models/) in our system tests. A "Page" here is generally corresponds to an overarching ember route, e.g. "Topic" for `/t/324345/some-topic`, and this contains logic for querying components within the topic such as "Posts". I have also split "Modals" into their own entity. Further down the line we may want to explore creating independent "Component" contexts. Capybara DSL should be included in each PageObject class, reference for this can be found at https://rubydoc.info/github/teamcapybara/capybara/master#the-dsl For system tests, since they are so slow, we want to focus on the "happy path" and not do every different possible context and branch check using them. They are meant to be overarching tests that check a number of things are correct using the full stack from JS and ember to rails to ruby and then the database. ### CI Setup Whenever a system spec fails, a screenshot is taken and a build artifact is produced _after the entire CI run is complete_, which can be downloaded from the Actions UI in the repo. Most importantly, a step to build the Ember app using Ember CLI is needed, otherwise the JS assets cannot be found by capybara: ``` - name: Build Ember CLI run: bin/ember-cli --build ``` A new `--build` argument has been added to `bin/ember-cli` for this case, which is not needed locally if you already have the discourse rails server running via `bin/ember-cli -u` since the whole server is built and set up by default. Co-authored-by: David Taylor <david@taylorhq.com>
2022-09-27 21:48:16 -04:00
selenium-webdriver
shoulda-matchers
2014-02-23 18:00:25 -05:00
sidekiq
simplecov
sprockets (= 3.7.2)
2017-08-22 22:58:25 -04:00
sprockets-rails
sshkey
stackprof
test-prof
thor
2013-02-05 14:16:51 -05:00
uglifier
unf
unicorn
DEV: Minimal first pass of rails system test setup (#16311) This commit introduces rails system tests run with chromedriver, selenium, and headless chrome to our testing toolbox. We use the `webdrivers` gem and `selenium-webdriver` which is what the latest Rails uses so the tests run locally and in CI out of the box. You can use `SELENIUM_VERBOSE_DRIVER_LOGS=1` to show extra verbose logs of what selenium is doing to communicate with the system tests. By default JS logs are verbose so errors from JS are shown when running system tests, you can disable this with `SELENIUM_DISABLE_VERBOSE_JS_LOGS=1` You can use `SELENIUM_HEADLESS=0` to run the system tests inside a chrome browser instead of headless, which can be useful to debug things and see what the spec sees. See note above about `bin/ember-cli` to avoid surprises. I have modified `bin/turbo_rspec` to exclude `spec/system` by default, support for parallel system specs is a little shaky right now and we don't want them slowing down the turbo by default either. ### PageObjects and System Tests To make querying and inspecting parts of the page easier and more reusable inbetween system tests, we are using the concept of [PageObjects](https://www.selenium.dev/documentation/test_practices/encouraged/page_object_models/) in our system tests. A "Page" here is generally corresponds to an overarching ember route, e.g. "Topic" for `/t/324345/some-topic`, and this contains logic for querying components within the topic such as "Posts". I have also split "Modals" into their own entity. Further down the line we may want to explore creating independent "Component" contexts. Capybara DSL should be included in each PageObject class, reference for this can be found at https://rubydoc.info/github/teamcapybara/capybara/master#the-dsl For system tests, since they are so slow, we want to focus on the "happy path" and not do every different possible context and branch check using them. They are meant to be overarching tests that check a number of things are correct using the full stack from JS and ember to rails to ruby and then the database. ### CI Setup Whenever a system spec fails, a screenshot is taken and a build artifact is produced _after the entire CI run is complete_, which can be downloaded from the Actions UI in the repo. Most importantly, a step to build the Ember app using Ember CLI is needed, otherwise the JS assets cannot be found by capybara: ``` - name: Build Ember CLI run: bin/ember-cli --build ``` A new `--build` argument has been added to `bin/ember-cli` for this case, which is not needed locally if you already have the discourse rails server running via `bin/ember-cli -u` since the whole server is built and set up by default. Co-authored-by: David Taylor <david@taylorhq.com>
2022-09-27 21:48:16 -04:00
webdrivers
2017-04-15 00:11:02 -04:00
webmock
2018-05-07 05:09:58 -04:00
webpush
xorcist
yaml-lint
BUNDLED WITH
2.3.22