Add support to override manifest_path as a configuration #195
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What is the problem this is solving?
The current implementation has a hardcoded manifest path making it difficult to adapt to various deployment scenarios.
In my scenario, a Docker image needs to be be built for the application to be deployed. The build process works as follows:
public/assets
directory is cached across builds by default.public/assets
is mounted at the beginning of the image build process.rails assets:precompile
is executed.public/assets
are uploaded to a cloud bucket.public/assets
is unmounted.When the docker container is started in a production environment, the
public/assets
folder does not exist in the local path as all the files are served through the CDN. This causes Propshaft to use the Dynamic resolver, which needs to compute all asset digests at runtime.The code changes prevents Propshaft from using the Dynamic resolver and allows the Static resolver to be used even if
public/assets
is absent in the local path which is ideal for setups where assets are served via CDN.