Is it possible to pass in a public_output_path dynamically when running compilation?

[green3g]

I'm trying to use a cdn for deployment of application assets, and I"d like to be able to maintain multiple versions of these assets in the cdn, so when we do new deploys, the application can request the new versions of the assets, and we can easily test our and/or roll back between multiple versions of assets when different apps get deployed. To do so, I'm setting up an s3 bucket with prefixes corresponding to version numbers of the application, IE: /v1.2.3/packs, /v1.2.3/assets, etc.

I'd like to change the output path for the built files when shakapacker runs - the motivation is to use an environment variable in the environment to output the shakacker build.

For example, I want to change the path based on the version of my application ->

CI_COMMIT_REF=v1-2-3
ASSET_PREFIX=$CI_COMMIT_REF bundle exec rails assets:precompile

  # config/shakapacker.yml
  public_output_path: <%= Rails.configuration.assets.prefix %>/packs

which would put files in public/v1-2-3/packs/*

Is this possible in current features?

[tomdracz]

@green3g I don't see a super-clean way of doing this. One idea would be to create some versioned shakapacker.yml that will have your versioned public_output_path. You can then pass the path to the file using ENV variable SHAKAPACKER_CONFIG to override the config from default shakapacker.yml

[green3g]

@tomdracz I've actually found a different approach that appears to be working. Seems this feature in Shakapacker wasn't really an issue. I am a little curious though how to continue accomplishing this workflow once relative_url_root goes away. Details below.

To solve this problem of hosting assets on a cdn in side a subdirectory, here's what I found out:

1. before building, set environment variable RAILS_RELATIVE_URL_ROOT=/prefix

This sets the build prefix for the css so that all the paths are prefixed with the specified path.

2. Build assets bundle exec rake assets:precompile --trace

3. Upload public/* to the cdn

4. On the production application host, set environment variable ASSET_HOST=https://cdn.url.com/prefix

When using this approach I get a message of

The usage of relative_url_root is deprecated in Shakapacker and will be removed in v8.

so I'm curious how to continue supporting this workflow

[tomdracz]

@green3g I must try this as I'm quite surprised. I don't see any place in the code where we would pick RAILS_RELATIVE_URL_ROOT and relative_url_root from Shakapacker also is unused.

Are you saying that setting that ENV RAILS_RELATIVE_URL_ROOT by itself is enough for the assets to end up in a prefixed folder? What version of Shakapacker and Rails are you using?

Really curious, need to dig closer to see where this is coming from!

[tomdracz]

TLDR; as you were, relative_url_root in Shakapacker being removed will have absolutely zero effect on anything (unless something in your setup directly references Shakapacker.instance.config.relative_url_root which is unlikely)

Long version:
OK, I've tested this and can't quite see how/why it would work. Certainly doesn't seem to have anything to do with Shakapacker. I don't see setting RAILS_RELATIVE_URL_ROOT=/prefix before precompilation having any effect.

I think this might be doing something on Rails side and having script tags etc prefixed with /prefix because RAILS_RELATIVE_URL_ROOT is normally used to indicate that Rails app is mounted in sub-dir.

From Webpacker/Shakapacker side any usage of this was removed in rails/webpacker#2151

If this is working for you, then all good, I don't think Shakapacker deprecating relative_url_root will have any effect on this setup whatsoever, because again, we're simply not using this config or env variables anywhere. We've marked them for deprecation as noticed the lack of use but deprecated first rather than removing just in case some setup depended on it.

[green3g]

Are you saying that setting that ENV RAILS_RELATIVE_URL_ROOT by itself is enough for the assets to end up in a prefixed folder? What version of Shakapacker and Rails are you using?

I'm sorry, I wasn't quite explaining it correctly. What I'm doing now is copying the entire public/ directory up to a prefixed folder on the CDN. I discovered that I didn't need shakapacker to output files into a subdirectory, what I did need though was to tell the build process about the prefix so that css files could correctly reference files on the cdn. The issue I was having is that some CSS files would reference /assets/... and I needed them to reference /v1.2.3/assets/.

From what it sounds like Shakapacker has no concern with this, its really just the rails asset pipeline. Thank you for taking a look at the shakapacker side of things!