We were running into errors running `ember build` on machines with high
CPU counts. It was then noted that `thread-loader`, which embroider uses, defaults to spinning
up x workers where x is number of physical CPU cores - 1. That is
probably too much so we set out to find out an optimial count to set for
the `JOBS` env which embroider will use to set the number of
`thread-loader` workers.
I first built an image using the following Dockerfile.
```
FROM discourse/base:release
RUN cd /var/www/discourse && sudo -EH -u discourse bundle exec rake plugin:install_all_official
RUN cd /var/www/discourse && sudo -EH -u discourse bundle exec rake assets:precompile:prereqs
```
I then ran the following command on my M3 Max Macbook Pro that has 14
phyisal CPU cores.
```
for j in 1 2 4 8 14; do echo "JOBS=$j"; time docker run --rm -it -e JOBS=$j test:latest /bin/bash -c "su discourse -c 'cd /var/www/discourse && bundle exec rake assets:precompile:build'"; done
```
These are the results I got:
```
JOBS=1 0.04s user 0.03s system 0% cpu 1:01.92 total
JOBS=2 0.04s user 0.02s system 0% cpu 42.605 total
JOBS=4 0.04s user 0.02s system 0% cpu 37.012 total
JOBS=8 0.04s user 0.02s system 0% cpu 35.199 total
JOBs=14 0.04s user 0.02s system 0% cpu 37.941 total
```
We think JOBS=2 is a good default when the `JOBS` env has not been set.
Anything above just consumes more resources for little benefit.
We're seeing a problem where some recurring automations end up in a state where they don't have any `pending_automations` records scheduled which effectively makes the recurring automation dead. We need to add some debugging to figure out what might be causing this problem.
Internal topic: t/138045.
These fields are often used when serializing topics which may contain
multiple polls. On average, serializing a poll took 2+N queries where N
is the number of options. This change reduces the number of queries to
3, one for each field (Poll#voters_count, PollOption#voters_count and
Poll#has_voted?).
This commit adds a new `about_page_hidden_groups` setting to exclude members of specific groups from the admin and moderator lists on the /about page.
Internal topic: t/137717.
On occasion we get an error popup on desktop due to the channel not being found.
This change means that we only check the cached channels in ChatChannelsManager for the matching channel id, but we skip doing manual lookup which results in ajax popup when it fails.
* FIX: add "in:first" to user summary category search
The "in:first" parameter was added to the search parameters for the topic count in the user summary category search.
This ensures that the search results focus specifically on the first posts in each topic, so only topics are returned.
Meta topic: https://meta.discourse.org/t/summary-page-by-category-topic-links/215848
* add tests
Provided by @natsw
This commit converts the current chat plugin UI into the
new "show plugin" UI already followed by AI and Gamification.
In the process, I also:
* Made a dedicated /new route to create new webhooks
* Converted the webhook form to FormKit
* Made some fixes and improvements to the `AdminPluginConfigPage`, `AdminPageHeader`,
and `AdminPageSubheader` generic components, so more plugins can
adopt the UI guidelines too. This includes adding a header outlet so plugins
can add action buttons to the plugin show page header.
* Fixes the submit button loading state for FormKit (by Joffrey)
---------
Co-authored-by: Joffrey JAFFEUX <j.jaffeux@gmail.com>
Followup 14b436923c5b582cea454b69441a28e16f2f191e
On the standalone Site Traffic report page, we also need
to hide the 'other' and 'crawler' pageviews by default
like we do on the admin dashboard.
### UI changes
All of the UI changes described are gated behind the `use_legacy_pageviews`
site setting.
This commit changes the admin dashboard pageviews report to
use the "Consolidated Pageviews with Browser Detection" report
introduced in 2f2da7274732cba30d03b6c5c3a4194652cb6783 with
the following changes:
* The report name is changed to "Site traffic"
* The pageview count on the dashboard is counting only using the new method
* The old "Consolidated Pageviews" report is renamed as "Consolidated Legacy Pageviews"
* By default "known crawlers" and "other" sources of pageviews are hidden on the report
When `use_legacy_pageviews` is `true`, we do not show or allow running
the "Site traffic" report for admins. When `use_legacy_pageviews` is `false`,
we do not show or allow running the following legacy reports:
* consolidated_page_views
* consolidated_page_views_browser_detection
* page_view_anon_reqs
* page_view_logged_in_reqs
### Historical data changes
Also part of this change is that, since we introduced our new "Consolidated
Pageviews with Browser Detection" report, some admins are confused at either:
* The lack of data before a certain date , which didn’t exist before
we started collecting it
* Comparing this and the current "Consolidated Pageviews" report data,
which rolls up "Other Pageviews" into "Anonymous Browser" and so it
appears inaccurate
All pageview data in the new report before the date where the _first_
anon or logged in browser pageview was recorded is now hidden.
Previously we were opening the file handles, then putting them in a queue for upload. If that queue grows too large, we can hit a maximum open files limit.
This commit opens the file handle 'just in time', so the maximum number of open handles is equal to the upload concurrency (20).
* Updates GitHub Actions
* Switches from `bundler/inline` to an optional group in the `Gemfile` because the previous solution didn't work well with rspec
* Adds the converter framework and tests
* Allows loading private converters (see README)
* Switches from multiple CLI tools to a single CLI
* Makes DB connections reusable and adds a new abstraction for the `IntermediateDB`
* `IntermediateDB` acts as an interface for IPC calls when a converter steps runs in parallel (forks). Only the main process writes to the DB.
* Includes a simple example implementation of a converter for now.
* FEATURE: Log tag group changes in staff action log
This commit records every change (add, change, delete) to a tag group in
the staff action log.
It uses a modal that was originally called ThemeChangeModal to display
changes, allowing staffs to see the specific changes clearly. The modal
is renamed to StaffActionLogChangeModal in this PR.
ref: https://meta.discourse.org/t/-/325011/14
Co-authored-by: Keegan George <kgeorge13@gmail.com>
The latest node 22.7.0 based release of mini_racer disabled
Maglev (https://v8.dev/blog/maglev) based optimisations
From previous segfaults it appears the failures happened in the maglev code
paths.
Node release of v8 lags latest release of v8 so, whatever is happening, may
be resolved in latest.
