I am bundling using Webpack 4.
I have multiple Webpack configurations exported in webpack.config.js.
First configuration is to bundle lient code targeting browsers.
Second configuration is to bundle server code targeting node.
I am specifying these browsers and node targets using browserslist in package.json.
I need to specify different browserslists for client and server bundles, but I only have one browserslist key in package.json.
How can I specify different browserslists using package.json?
You don't have to use package.json. If you create a file called .browserslistrc or browserslist at the root of your project, you can use a different configuration.
# Any general config goes at the very top, above any section headers
# ...
# Put section headers in [brackets]
[node]
supports es6-modules
[web]
>1% and not dead
Then call webpack and set BROWSERSLIST_ENV:
BROWSERSLIST_ENV=dev webpack -c webpack.dev.js # Build development
BROWSERSLIST_ENV=prod webpack -c webpack.prod.js # Build production
Your webpack command may be different depending on your configuration.
Related
When working with a ColdFusion server you can access the CFIDE/administrator to set config values, which update the cfusion/lib/ xml files (e.g. neo-runtime.xml, neo-mail.xml, etc.)
I'd like to automate a deployment process that includes setting these administrator values so that I don't have to log in and manually set them for each new box that shares settings. I'm unsure of the best way to go about it.
Some thoughts I had are:
Replacing the full files with ones containing my custom settings. I've done this for local development, but it may not be an ideal method due to CF hot-fixes potentially adding/removing/changing attributes.
A script to read the wddx xml file and replace the attribute values. I'm having trouble finding information about how to do this method.
Has anyone done anything like this before? Or does anyone have any recommendations on how to best go about this?
At one company, we checked all the neo-*.xml files into source control, with a set for each environment Devs only had access to the dev settings and we could deploy a local development environment with all the correct settings for new employees quickly.
but it may not be an ideal method due to CF hot-fixes potentially adding/removing/changing attributes.
You have to keep up with those changes and migrate each environment appropriately.
While I was there, we upgraded from 8 to 9, 9 to 11 and from 11 to 2016. Environments would have to be mixed as it took time to verify the applications worked with each new version of CF. Each server got their correct XML files for that environment and scripts would copy updates as needed. We had something like 55 servers in production running 8 instances each, so this scaled well.
There is a very usefull tool developed by Ortus Solutions for this kind of automatizations called cfconfig that can be installed with their commandbox command line utility. This tool isn't only capable of setting configurations of the administrator: It is also capable of exporting/importing settings to a json file (cfconfig.json). It might be what you need.
Here is the link to their docs
https://cfconfig.ortusbooks.com/introduction/getting-started-guide
CFConfig worked perfectly for my needs. I marked #AndreasRu answer as accepted for introducing me to that tool! I'm just adding this response with some additional detail for posterity.
Install CommandBox as part of deployment script
Install CFConfig as part of deployment script
Use CFConfig to export a config.json file from an existing box that will share settings with the new deployment. Store this json file in source control for each type/env of box.
Use CFConfig to import the config.json as part of deployment script
Here's a simple example of what this looks like on debian
# Installs CommandBox
curl -fsSl https://downloads.ortussolutions.com/debs/gpg | apt-key add -
echo "deb https://downloads.ortussolutions.com/debs/noarch /" | tee -a /etc/apt/sources.list.d/commandbox.list
apt-get update && apt-get install apt-transport-https commandbox
# Installs CFConfig module
box install commandbox-cfconfig
# Import config settings
box cfconfig import from=/<path-to-config>/config.json to=/opt/ColdFusion/cfusion/ toFormat=adobe#11.0.19
Let's say I have a C++ project, which depends on an external package, which is fetched (by using a given git tag or source path) from the web as the first stage, then its artifact is passed to the job which builds my project.
I would like to speed up the build by caching the build of the dependency package somehow.
Ideally, I would like to build that external package once, then cache it for the subsequent pipelines without re-build it at the start of a new pipeline.
Then, if the git tag or the source path I use to fetch the external package changes (which would be the sign that I'm using a different version of the external package), then the package is built again and the cache replaced with the new version.
I'm trying to get this use-case from various pieces of GitLab CI documentation but I cannot find the right answer.
Does the template not work? link: https://gitlab.com/gitlab-org/gitlab-foss/-/blob/master/lib/gitlab/ci/templates/Python.gitlab-ci.yml
...
# Change pip's cache directory to be inside the project directory since we can
# only cache local items.
variables:
PIP_CACHE_DIR: "$CI_PROJECT_DIR/.cache/pip"
# Pip's cache doesn't store the python packages
# https://pip.pypa.io/en/stable/reference/pip_install/#caching
#
# If you want to also cache the installed packages, you have to install
# them in a virtualenv and cache it as well.
cache:
paths:
- .cache/pip
- venv/
...
I cloned a rails project from github and trying to run rails generate rspec:install after running bundle install. The console gives following
`Usage:
rails new APP_PATH [options]
Options:
-r, [--ruby=PATH] # Path to the Ruby binary of your choice
# Default: /Users/sankethpurwar/.rvm/rubies/ruby-2.3.1/bin/ruby
-m, [--template=TEMPLATE] # Path to some application template (can be a filesystem path or URL)
[--skip-gemfile], [--no-skip-gemfile] # Don't create a Gemfile
-B, [--skip-bundle], [--no-skip-bundle] # Don't run bundle install
-G, [--skip-git], [--no-skip-git] # Skip .gitignore file
[--skip-keeps], [--no-skip-keeps] # Skip source control .keep files
-O, [--skip-active-record], [--no-skip-active-record] # Skip Active Record files
-S, [--skip-sprockets], [--no-skip-sprockets] # Skip Sprockets files
-d, [--database=DATABASE] # Preconfigure for selected database (options: mysql/oracle/postgresql/sqlite3/frontbase/ibm_db/sqlserver/jdbcmysql/jdbcsqlite3/jdbcpostgresql/jdbc)
# Default: sqlite3
-j, [--javascript=JAVASCRIPT] # Preconfigure for selected JavaScript library
# Default: jquery
-J, [--skip-javascript], [--no-skip-javascript] # Skip JavaScript files
[--dev], [--no-dev] # Setup the application with Gemfile pointing to your Rails checkout
[--edge], [--no-edge] # Setup the application with Gemfile pointing to Rails repository
-T, [--skip-test-unit], [--no-skip-test-unit] # Skip Test::Unit files
[--rc=RC] # Path to file containing extra configuration options for rails command
[--no-rc], [--no-no-rc] # Skip loading of extra configuration options from .railsrc file
Runtime options:
-f, [--force] # Overwrite files that already exist
-p, [--pretend], [--no-pretend] # Run but do not make any changes
-q, [--quiet], [--no-quiet] # Suppress status output
-s, [--skip], [--no-skip] # Skip files that already exist
Rails options:
-h, [--help], [--no-help] # Show this help message and quit
-v, [--version], [--no-version] # Show Rails version number and quit
Description:
The 'rails new' command creates a new Rails application with a default
directory structure and configuration at the path you specify.
You can specify extra command-line arguments to be used every time
'rails new' runs in the .railsrc configuration file in your home directory.
Note that the arguments specified in the .railsrc file don't affect the
defaults values shown above in this help message.
Example:
rails new ~/Code/Ruby/weblog
This generates a skeletal Rails installation in ~/Code/Ruby/weblog.
See the README in the newly created application to get going.`
Do I need to do any additional setup to work with an existing code base?
I think you are not running generator command from project directory. go to your project directory then run the command. If bundler in not installed then run gem install bundler after that run bundle install
I want to have a manifest in my ember app, because I want to use it on mobile devices and have some offline capabilities.
I have found the plugin ember-cli-deploy-manifest:
https://github.com/ember-cli-deploy/ember-cli-deploy-manifest
It is well documented in the readme and looked promising.
But how do I use the plugin?
I have installed it using this command:
ember install ember-cli-deploy-manifest
I build my app using this command:
ember build -prod
No manifest is created. I am probably missing some simple step, but can't figure it out. How do I tell ember build to use the plugin?
UPDATE
I followed the suggestion in the comment of the answer below. I dropped using the manifest-plugin and created a manifest file manually. Then the challenge is to get proper fingerprinted filenames in the manifest file.
In my ember-cli-build.js file I have:
module.exports = function(defaults) {
var app = new EmberApp(defaults, {
fingerprint: {
exclude: [],
extensions: ['js', 'css', 'png', 'jpg', 'gif', 'map'],
replaceExtensions: ['html','css','js', 'appcache']
}
});
...
My manifest file is called eea.appcache and is located in the /public folder. It is copied to the dist-folder during build.
However the content of the file (the list of filenames) are not fingerprinted. Filenames in the other files (html, css, js) are fingerprinted correctly.
Here is my public/eea.appcache:
CACHE MANIFEST
# 2016-03-15
# V 1.0
CACHE:
index.html
assets/vendor.css
assets/eea.css
assets/vendor.js
assets/eea.js
assets/img/Icon120x120.png
My buildstep is still:
ember build -prod
How to get the filenames in the manifets files updated with the MD5 fingerprint?
The ember-cli-deploy-manifest is for use with ember-cli-deploy.
So you need to run ember deploy -production once you have installed ember deploy.
Install ember-cli-deploy
ember install ember-cli-deploy
Then
ember deploy -production
I finally got it to work, but this solution is really hack'ish.
I figured this out by trial and error.
The broccoli-assets-rev has some tricky rules when it parses a file to find the filenames. The format that are normally used in a manifest file the filenames are not found by the parser.
But if the files are listed in the comments of the file with quotes and correct path is used, it will work.
If the manifest file is located in the root of the public folder it will end up in the root of the webpage. Then the paths will be as below.
My file looks like this:
CACHE MANIFEST
# 2016-03-15
# V 1.1
# '
# 'assets/vendor.css'
# 'assets/eea.css'
# 'assets/vendor.js'
# 'assets/eea.js'
# 'assets/img/Icon120x120.png'
CACHE:
index.html
assets/vendor.css
assets/eea.css
assets/vendor.js
assets/eea.js
assets/img/Icon120x120.png
NETWORK
*
Then the resulting built file looks like this:
CACHE MANIFEST
# 2016-03-15
# V 1.1
#
# 'assets/vendor-d41d8cd98f00b204e9800998ecf8427e.css'
# 'assets/eea-ddacde3bdf32d3f94c5a01a2054c6f72.css'
# 'assets/vendor-3229c2c849c3d52c0b362d9fee2106ad.js'
# 'assets/eea-4c760118f51f7402db2f0b6074b6960b.js'
# 'assets/img/Icon120x120-40b31b55211fb293dedf556a648aa47e.png'
CACHE:
index.html
assets/vendor-d41d8cd98f00b204e9800998ecf8427e.css
assets/eea-ddacde3bdf32d3f94c5a01a2054c6f72.css
assets/vendor-3229c2c849c3d52c0b362d9fee2106ad.js
assets/eea-4c760118f51f7402db2f0b6074b6960b.js
assets/img/Icon120x120-40b31b55211fb293dedf556a648aa47e.png
NETWORK
*
I have an application that is built with a build script named linuxApp.gradle. We have specified in settings.gradle
rootProject.name = "JobThreader"
As long as the root project folder is also named "JobThreader", when we execute the installApp task from the application plugin, the application is built to
JobThreader/build/install/JobThreader
However, if the root project folder is any other name, like "workspace" in the case of Jenkins, then the application is built to
workspace/build/install/workspace
We have verified this behavior both on our Linux Jenkins server and our local Windows machine.
We have attempted the following commands with identical results
gradlew clean installApp -b linuxApp.gradle
gradlew clean installApp -b linuxApp.gradle -c settings.gradle
How can we get the application to install to workspace/build/install/JobThreader in our Jenkins example?
When -b is used, any settings script will be ignored. (-b can be useful for experimentation, but isn't typically used for real builds.) When -b is not used and a settings script is found or passed explicitly via -c, it's up to that settings script to configure the names of build scripts. For example:
rootProject.buildFileName = "linuxApp.gradle"