Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Devstack edxapp static assets are not available #65

Open
2 tasks
timmc-edx opened this issue Nov 1, 2024 · 1 comment
Open
2 tasks

Devstack edxapp static assets are not available #65

timmc-edx opened this issue Nov 1, 2024 · 1 comment
Assignees

Comments

@timmc-edx
Copy link
Member

timmc-edx commented Nov 1, 2024

A/C:

  • Static assets available in a fresh provision of lms/cms
  • Notes added to "Past problems (fixed)" section of devstack's docs/troubleshoot_general_tips.rst

In a fresh re-provision of devstack in late October 2024, the static assets builds for lms and cms appear to run successfully, but the sites serve an error page like this:

OSError: Error reading /edx/var/edxapp/staticfiles/webpack-stats.json. Are you sure webpack has generated the file and the path is correct?

As it turns out, the static assets are all present in that parent directory (/edx/var/edxapp/staticfiles/) and the only thing that's missing is the webpack-stats.json itself -- instead, it is written to /edx/app/edxapp/edx-platform/test_root/staticfiles/ (and same for ./studio/webpack-stats.json). Moving these stats files to the right place causes them to work again.

Likely the fix will involve adjusting environment variables STATIC_ROOT_LMS/CMS or related Django settings. edxapp has the following line in webpack.common.config.js: var staticRootLms = process.env.STATIC_ROOT_LMS || './test_root/staticfiles'; -- and yes, /edx/app/edxapp/edx-platform/test_root/staticfiles exists. That's where the files are ending up! Probably this is fallout from the Paver removal mid-2024, and some of the needed config changes just didn't make it into devstack.

@timmc-edx timmc-edx self-assigned this Nov 4, 2024
timmc-edx added a commit that referenced this issue Nov 4, 2024
After the removal of paver, static assets build wasn't completing properly
in edxapp -- static files were written to the correct directory in the
assets volume (mounted under /edx/var) but the webpack-stats.json files
were written to the test_root dir in the app container (under /edx/app).
The service would fail on first page load as it failed to find the stats
file, which is apparently used for locating resources.

The static assets build was also taking quite a long time and a lot of CPU,
which is likely because we were doing the production-style build with full
optimization.

- Set static-root environment variables so that webpack-stats.json is
  written to the right place. See `staticRootLms` and `staticRootCms` in
  `webpack.common.config.js` in edx-platform for where that default is set.
  Set both LMS/CMS vars for both lms and cms since there's some dependency
  of CMS on LMS in the logic (and both calls build both sets of files, for
  better or worse).
- Use npm dev build for reduced optimization (faster build).

Also:

- Use same spelling of `--no-input` for both calls (either works, just
  make it uniform)

Addresses #65
timmc-edx added a commit that referenced this issue Nov 4, 2024
After the removal of paver, static assets build wasn't completing properly
in edxapp -- static files were written to the correct directory in the
assets volume (mounted under /edx/var) but the webpack-stats.json files
were written to the test_root dir in the app container (under /edx/app).
The service would fail on first page load as it failed to find the stats
file, which is apparently used for locating resources.

The static assets build was also taking quite a long time and a lot of CPU,
which is likely because we were doing the production-style build with full
optimization.

- Set static-root environment variables so that webpack-stats.json is
  written to the right place. See `staticRootLms` and `staticRootCms` in
  `webpack.common.config.js` in edx-platform for where that default is set.
  Set both LMS/CMS vars for both lms and cms since there's some dependency
  of CMS on LMS in the logic (and both calls build both sets of files, for
  better or worse).
- Use npm dev build for reduced optimization (faster build).

Also:

- Use same spelling of `--no-input` for both calls (either works, just
  make it uniform)

Addresses #65
@timmc-edx
Copy link
Member Author

#66 should fix this -- will test a fresh re-provision before getting it reviewed though.

timmc-edx added a commit that referenced this issue Nov 4, 2024
After the removal of paver, static assets build wasn't completing properly
in edxapp -- static files were written to the correct directory in the
assets volume (mounted under /edx/var) but the webpack-stats.json files
were written to the test_root dir in the app container (under /edx/app).
The service would fail on first page load as it failed to find the stats
file, which is apparently used for locating resources.

The static assets build was also taking quite a long time and a lot of CPU,
which is likely because we were doing the production-style build with full
optimization.

- Set static-root environment variables so that webpack-stats.json is
  written to the right place. See `staticRootLms` and `staticRootCms` in
  `webpack.common.config.js` in edx-platform for where that default is set.
  Set both LMS/CMS vars for both lms and cms since there's some dependency
  of CMS on LMS in the logic (and both calls build both sets of files, for
  better or worse).
- Use npm dev build for reduced optimization (faster build).
- Use `--settings devstack_docker` in the Makefile call to collectstatic;
  I'm not actually sure what the impact of that is, but it's what was in
  the provisioning script's version of the call and I needed to deduplicate
  these calls.
- Have `provision-lms.sh` just call the Makefile so that there aren't two
  sources of truth on how to build static assets for edxapp.

Also:

- Use same spelling of `--no-input` for both calls (either works, just
  make it uniform)

Addresses #65
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: In Progress
Development

No branches or pull requests

1 participant