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

CDN host for staging environments #1922

Closed
kpelelis opened this issue Jan 29, 2019 · 2 comments
Closed

CDN host for staging environments #1922

kpelelis opened this issue Jan 29, 2019 · 2 comments

Comments

@kpelelis
Copy link
Contributor

kpelelis commented Jan 29, 2019

Webpacker version: 4.0.0.rc7
Rails Version: 5.1.6

Greetings! We have integrated webpacker into our asset pipeline and now we are in the process of updating it to v4 in order to be in sync with the latest updates. Both testing and development environments are working just fine but we are facing some issues our staging environment which,is almost a mirror of the production setup.

Our assets are built using our build server with RAILS_ENV=production and are then moved into the application servers. A key concept in this build server is that it only generates production builds, as we want to keep staging and production environments as similar as possible and also leverage incremental building.

One of the few differences that the staging environment has, is that we do not use CDNs to distribute our assets. With the introduction of #1084 the URLs generated by the Manifest Plugin are prefixed with the production asset server URL (which in our case is a CDN). Currently there is no way to opt out of this feature without generating staging specific builds. Is there a chance to make this feature opt-in? I can get onto the task if it a valid change.

For the shake of completeness, the manifest file now looks something like:

{
  "bundle1": "//my.cdn.com/assets/webpack/bundle1-abcdef0123456789.js"
}

Whereas before the update it looked like:

{
  "bundle1": "/assets/webpack/bundle1-abcdef0123456789.js"
}
@iggant
Copy link

iggant commented Jan 30, 2019

this is duplicate #1845

@guilleiguaran
Copy link
Member

Closing in favor of #1845

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants