refs FOO-2801
flag = none
[change-merged][build-registry-path=jenkins/canvas-lms/foo-2801]
[pin-commit-analytics=4fd9e2fbb7fc2790ba7985bb4025e901bf33a9e3]
this part reaches the goal of this series where we turn the locale
files that are used by our JS engine into plain JSON files that don't
need any special processing and are also of a simpler structure
before, translations were stored in a tree structure that we needed to
traverse in order to look up a translation, which we did by
deconstructing keys through the "." operator:
I18n.lookup("foo.bar.baz")
{
en: {
foo: {
bar: {
baz: "Hello!" // <-- this
}
}
}
}
now, translations are stored in a flat dictionary structure where the
keys are not processed in any special way but are instead "fully
qualified":
I18n.lookup("foo.bar.baz")
{
en: {
"foo.bar.baz": "Hello!"
}
}
this is nice when you consider that the previous structure contained a
mixture of nested keys and flat ones, based on different conditions:
{
en: {
"asdf_1234": "ASDF", // inferred, so it was never "nested"
"foo": {
"bar": {
"baz": {
"one": "One banana",
"other": "Many many bananas"
}
}
}
}
}
because, for example, keys that are inferred by i18nliner end up at
the root level and not nested. You also never knew whether a key was a
container or a phrase that was pluralized, because they both had the
shape of an object.
Now these distinctions are gone; a key is always fully-qualified
regardless of how it was specified:
1) inferred: I18n.t("Inferred key")
// => inferred_key_c49e3743
2) absolute: I18n.t('#buttons.cancel')
// => buttons.cancel
3) relative: I18n = useScope('outer')
I18n.t('something', 'Something')
// => outer.something
4) nested: I18n = useScope('outer');
I18n.t('something.inside', 'Something inside')
// => outer.something.inside
5) pluralized: I18n.t({
one: 'One banana',
other: 'Many bananas'
})
// => many_many_bananas_ce8e7fb7.one
// => many_many_bananas_ce8e7fb7.other
Change-Id: I7c33fbd2321d7d56994223d65f2572db0ac12ed5
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/293675
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
QA-Review: Charley Kline <ckline@instructure.com>
Reviewed-by: Charley Kline <ckline@instructure.com>
Product-Review: Charley Kline <ckline@instructure.com>
Note: Ensure that istanbul is only enabled for crystalball before
this is merged
closes OUT-4918
flag=none
Test-plan:
- crystalball map should include JS files
- ensure that CRYSTALBALL_MAP isn't set to 1 in standard pre-merge
Change-Id: I5ae2f32177640e3caeb77871918644890eb4ae30
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/280813
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: James Butters <jbutters@instructure.com>
QA-Review: Brian Watson <bwatson@instructure.com>
Product-Review: Brian Watson <bwatson@instructure.com>
refs FOO-2520
flag = none
[pin-commit-multiple_root_accounts=2a9bf89895f38df6bf8f54828af66aced594abf0]
revisit the API for resolving asset names to their (real)path on disk,
because adding to the existing logic to support an alternative bundler
made things hard to understand.
This patch brings a new simplified interface Canvas::Cdn::Registry to
query assets and resolve their location.
- Registry#include?(path) tells whether a realpath points to a static
asset
- Registry#statics_available? tells whether static assets are available
- Registry#scripts_available? tells whether JS assets are available
- Registry#scripts_for(bundle) provides the realpaths to all the JS
files in the specified bundle
- Registry#url_for(name) provides the realpath to the static asset
The Registry is a good place to house the BrandableCSS resolving logic
in the future for even more consistency. It can also support an
alternative bundler internally without leaking. Eventually, it would be
nice to have it as a gem.
CHANGES
-------
- helper "font_url_for()" has been removed as it was a duplicate of
existing logic; instead use "font_path(...)" to achieve the correct
result. As a result, BrandableCSS is no longer querying Gulp's
manifest.
- preloaded fonts are now aware of the asset host and work for CDN
- InfoController uses the new Registry API to tell whether Gulp and
Webpack have produced their assets successfully
- ApplicationHelper no longer re-computes the base URL for JavaScripts,
now only the Registry is concerned with that
- ?optimized_js query parameter is no longer supported as it has no real
benefit now that we have access to sourcemaps on production
- ENV['USE_OPTIMIZED_JS'] is now more consistent as there is a single
source of truth for it. The Registry can be instantiated with
{environment: "production"} to point to the optimized version of the
scripts.
- "css:compile" task no longer writes BrandConfig records to the DB,
that is now done as part of the "compile_assets" task, which you can
opt out of doing by setting COMPILE_ASSETS_BRAND_CONFIGS=0
TEST PLAN
---- ----
- load your dashboard and verify all the assets are loaded correctly
- set up a CDN, restart your Rails server and reload the dashboard
- verify all assets are loaded from the CDN
- verify the Lato fonts are pre-loaded from the CDN
- (optional) add custom JS to a sub-account and visit it
- verify the custom JS is loaded and evaluated *after* Canvas's main
javascript bundles
Change-Id: I8198de747cdd5892d6a831cb6c61ba0ef9afa789
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/276537
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
QA-Review: James Butters <jbutters@instructure.com>
Reviewed-by: Charley Kline <ckline@instructure.com>
Product-Review: Charley Kline <ckline@instructure.com>
refs DE-517
Disable locales on pre-merge Jenkins build in order to save ~25s on builds that require webpack to recompile. This also lets us clean up the code that builds the js-runner image. Pre-merge builds will still verify the i18n tasks in the Linters job, and post-merge builds will continue to build / run all tests using locales.
[build-registry-path=jenkins/canvas-lms/de-517]
[change-merged]
Change-Id: I8ded5d675b72d713738307403502f459adc79a73
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/258197
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Andrea Cirulli <andrea.cirulli@instructure.com>
Reviewed-by: James Butters <jbutters@instructure.com>
QA-Review: Aaron Ogata <aogata@instructure.com>
Product-Review: Aaron Ogata <aogata@instructure.com>
refs DE-411
Now that we don’t share much less code between local docker dev & Jenkins, there is no need for a complicated template to generate these files.
Change-Id: I13ef071b7e468dc04bc8d47a1c55e8d2920e09f6
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/254810
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: James Butters <jbutters@instructure.com>
QA-Review: Aaron Ogata <aogata@instructure.com>
Product-Review: Aaron Ogata <aogata@instructure.com>
refs DE-407
Add the build arguments to the webpack-cache cache ID computation to prevent post- / pre- merge builds from using each others cache when we remove the prefix distinction.
[change-merged]
[build-registry-path=jenkins/canvas-lms/de-407]
Change-Id: I73d9eb2c908bcb7e5bc04152eccd8fac9791c943
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/254610
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Kyle Rosenbaum <krosenbaum@instructure.com>
QA-Review: Aaron Ogata <aogata@instructure.com>
Product-Review: Aaron Ogata <aogata@instructure.com>
[change-merged]
[build-registry-path=jenkins/canvas-lms/ruby-runner]
Test Plan:
1. Ensure that changing gems updates the whole image.
2. Ensure that changing npm updates the webpack builder image.
3. Ensure that changing webpack files are reflected in the final image.
4. Ensure that changing packages files are reflected in the final image.
5. Ensure that there are no speed regressions in fully-cached cases.
6. Ensure that caching works as expected.
Change-Id: Icef77195ff912bc0628f27eeda6780f262a8908a
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/252565
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: James Butters <jbutters@instructure.com>
QA-Review: Aaron Ogata <aogata@instructure.com>
Product-Review: Aaron Ogata <aogata@instructure.com>
Aaron Ogata