support being able to specify the path to the `.discharge.json` file
See original GitHub issueIt would be handy to have multiple .discharge.json
files per project, and then choose which to use for the deploy
command.
Issue Analytics
- State:
- Created 5 years ago
- Reactions:1
- Comments:7 (4 by maintainers)
Top Results From Across the Web
Using the JSON format in AWS Glue
You can use AWS Glue to read JSON files from Amazon S3, as well as bzip and gzip ... In your connection_options ,...
Read more >Collector source configuration not getting updated per ...
When a Collector starts it reads the syncSources parameter from the user.properties configuration file to determine the file path of the JSON ......
Read more >JSON Files - Spark 3.3.1 Documentation
Property Name Default Scope
primitivesAsString false read
prefersDecimal false read
allowComments false read
Read more >Server Configuration and Maintenance – Cutsforth Support
Define a transceiver–Configure your server fleet by modifying the .json file that installed to your server with InsightCM.
Read more >host.json reference for Azure Functions 2.x | Microsoft Learn
The host.json metadata file contains configuration options that affect all functions in a function app instance. This article lists the settings ...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
In the short term, we’d like to have a “staging” and “dogfood” bucket. In the longer term, we’d like to have a static deployment per branch. So basically the use-case is different environments / builds being deployed to different buckets.
@brandonweiss it seems that all your scenarios assume that the goal long-term is to have one bucket / configuration, or to quickly test changes in a different bucket.
What I’d like is to have two different configuration files at all times, such to enable features like
yarn deploy-dogfood
andyarn deploy-staging
. In our case, we may have slightly different bundles and slightly differentindex.html
files we’d like to deploy to different buckets.The complexity of this addition is basically negligible. It allows you to configure something that before was just a constant. Fortunately, the code is already written to handle this pretty well. It works the same by default. https://github.com/brandonweiss/discharge/pull/71
I think S3 + Cloudfront is a perfectly reasonable place to host a front-end application.