An ember-cli-deploy plugin to upload to s3
License: MIT License
Simple, flexible deployment for your Ember CLI app
ember install ember-cli-deploy
After installation, choose plugins matching your deployment environment, configure your deployment script appropriately and you're ready to start deploying.
Clone the repo and run npm install. To run tests,
npm test
![dependabot[bot] avatar](https://avatars.githubusercontent.com/in/29110?v=4 "dependabot[bot]")
I'm on ember-cli-deploy-s3 0.3.1, and I can't seem to connect to S3.
I noticed #64 & #59 - but I've got the fix for #59 and I just tried a new deploy using freshly generated AWS Root Credentials as a sanity check for #64, but still getting this error on s3#upload:
SignatureDoesNotMatch: The request signature we calculated does not match the signature you provided. Check your key and signing method.
Anyone else seeing this?
Moved from ember-cli-deploy/ember-cli-deploy#103
We should add details to the README to help people configure the CORS support for hosting their assets on S3.
I recently ran into a request to address a security vulnerability related to [email protected] which is being used by my application through [email protected] › [email protected] › [email protected] › [email protected]
Related vulnerability: https://arstechnica.com/information-technology/2021/09/npm-package-with-3-million-weekly-downloads-had-a-severe-vulnerability/?amp=1
It looks like [email protected] is using the latest version of [email protected] which resolves the problem.
Would it be possible to get an update to ember-cli-deploy-s3 to bump proxy-agent to the latest version?
Hi there, i'm from colombia and we have some shitty internet here, and I'm getting RequestTimeout: Your socket connection to the server was not read from or written to within the timeout period. Idle connections will be closed. pretty often, is there any way i can increase the timeout interval for uploading assets?, thanks
I see under distFiles it says that the files to upload are provided by the ember-cli-deploy-build plugin, but over there I don't see a way to specify a way to also include index.html to be added to context.distFiles so that this plugin picks it up and includes it.
Do I need to use the separate ember-cli-deploy-s3-index plugin for that? I would think not since the readme for this one says that should be possible.
Hello,
I'm doing lightning deploys (index.html to Redis served by nginx with a redis module and everything else to S3) and seeing that with the manifest plugin enabled and ENV.build.environment in config/deploy.js set to development, since files are NOT fingerprinted and renamed, the manifest file matches everything (since the file names stay the same in development mode), and nothing gets uploaded. I can work around this by deleting everything in my target S3 location, or by manually enabling all of the plugins in the lightning pack except for manifest.
Here's my set-up:
$ ember -v --verbose
version: 2.3.0
http_parser: 2.6.0
node: 5.5.0
v8: 4.6.85.31
uv: 1.8.0
zlib: 1.2.8
ares: 1.10.1-DEV
icu: 56.1
modules: 47
openssl: 1.0.2e
os: darwin x64
# cat package.json
{
"name": "ember-cli-skeleton",
"version": "0.0.2",
"description": "Small description for ember-cli-skeleton goes here",
"private": true,
"directories": {
"doc": "doc",
"test": "tests"
},
"scripts": {
"build": "ember build",
"start": "ember server",
"test": "ember test"
},
"repository": "",
"engines": {
"node": ">= 0.10.0"
},
"author": "",
"license": "MIT",
"devDependencies": {
"broccoli-asset-rev": "^2.2.0",
"ember-ajax": "0.7.1",
"ember-cli": "2.3.0",
"ember-cli-app-version": "^1.0.0",
"ember-cli-babel": "^5.1.5",
"ember-cli-dependency-checker": "^1.2.0",
"ember-cli-deploy": "0.5.1",
"ember-cli-deploy-build": "0.1.1",
"ember-cli-deploy-lightning-pack": "0.4.0",
"ember-cli-deploy-slack": "0.1.0",
"ember-cli-htmlbars": "^1.0.1",
"ember-cli-htmlbars-inline-precompile": "^0.3.1",
"ember-cli-inject-live-reload": "^1.3.1",
"ember-cli-qunit": "^1.2.1",
"ember-cli-release": "0.2.8",
"ember-cli-sri": "^2.0.0",
"ember-cli-uglify": "^1.2.0",
"ember-data": "^2.3.0",
"ember-disable-proxy-controllers": "^1.0.1",
"ember-export-application-global": "^1.0.4",
"ember-load-initializers": "^0.5.0",
"ember-resolver": "^2.0.3",
"loader.js": "^4.0.0"
}
}
#cat config/deploy.js |egrep -v '(^|\s+)//.*$|/\*(.|.\s)*?\*/'
var VALID_DEPLOY_TARGETS = [
'dev',
'prod'
];
module.exports = function(deployTarget) {
var ENV = {
build: {},
redis: {
host: 'REDACTED',
allowOverwrite: true,
keyPrefix: 'ember-cli-skeleton:index'
},
s3: {
accessKeyId: process.env.AWS_KEY,
secretAccessKey: process.env.AWS_SECRET,
bucket: 'REDACTED',
region: 'us-west-2',
prefix: 'ember-cli-skeleton'
}
};
ENV["revision-data"] = {
type: 'git-commit'
};
if (VALID_DEPLOY_TARGETS.indexOf(deployTarget) === -1) {
throw new Error('Invalid deployTarget ' + deployTarget);
}
if (deployTarget === 'dev') {
ENV.build.environment = 'development';
ENV.redis.keyPrefix = 'ember-cli-skeleton-dev:index';
ENV.s3.prefix = 'ember-cli-skeleton-dev';
ENV.plugins = ['build', 'revision-data', 'redis', 's3'];
}
if (deployTarget === 'prod') {
ENV.build.environment = 'production';
}
return ENV;
}
With the above config specifying ENV.plugins = ['build', 'revision-data', 'redis', 's3']; when deployTarget === 'dev', things work as expected and it skips the manifest step, so ALL files are re-uploaded to S3 and the site will update when I make changes and run ember deploy dev --activate. Commenting that line and letting all plugins run brings back the bug.
Please let me know if it'd be better to open this against the manifest plugin. I'm not entirely sure what the correct behavior in this case would be, but a plugin option to re-upload everything (overwriting duplicate files) or ignore the manifest are my naive ideas.
Thanks!
When building my Ember app, I am seeing this message:
NOTE: We are formalizing our plans to enter AWS SDK for JavaScript (v2) into maintenance mode in 2023.
Please migrate your code to use AWS SDK for JavaScript (v3).
I looks like ember-cli-deploy-s3 and ember-cli-deploy-s3-index both use [email protected]. The v3 of the SDK is in a new package/repo: https://github.com/aws/aws-sdk-js-v3
I'm sure if this was something being worked on already. Is help needed for updating to v3?
Had to add json extension to filePattern to also deploy those files to S3. Wondering if that shouldn't work by default. Used in the wild for example for:
manifest.json (PWA)ember-intl translation files (when not bundled into vendor, using publicOnly: true config)Currently the defaultMimeType option cannot be set, as it isn't passed through into the options hash in the upload function located in index.js file.
Fingerprinted files are guaranteed to never change.
The immutable tag in the cache-control header was recently added so that browsers no longer need to check for a fresh file and get a 304 response.
@lukemelia Any objections to me submitting a PR for this?
I have a ~/.aws/config file like this;
[profile default]
sso_start_url = https://example.com/start
sso_region = ap-southeast-2
sso_account_id = 123456789
sso_role_name = developer-access
region = ap-southeast-2
output = json
[profile app-test]
....
[profile app-staging]
....
Setting a profile in config like s3.profile = 'app-staging' does not seem to work, errors during s3 upload
AWS_SDK_LOAD_CONFIG=1 ember deploy staging
- CredentialsError: Missing credentials in config, if using AWS_CONFIG_FILE, set AWS_SDK_LOAD_CONFIG=1
at SharedIniFileCredentials.load (/home/boverton/Blake/teacher-ui-client/node_modules/.pnpm/[email protected]/node_modules/aws-sdk/lib/credentials/shared_ini_file_credentials.js:146:11)
(removing AWS_SDK_LOAD_CONFIG=1 does not help)
However, running the deploy like this does work (only if s3.profile is removed from config);
AWS_PROFILE="app-staging" AWS_SDK_LOAD_CONFIG=1 ember deploy staging
My question is... am I doing something wrong? Is this something that will/should end up working as part of the aws sdk v3 update over here #173 ?
Hi,
I am using ember-cli-deploy-aws, which uses this addon to put objects to an S3 bucket. Unfortunately all objects get the "Cache-Control: max-age=63072000" & "Expires: 1 Jan 2030" Metadata, which is not what you want for the index.html file.
Is there a way to configure those metadata on a per file basis?
Thank you!
Andrew
I am running Windows 7, 64 bit and am deploying with ember-cli-deploy 0.5.1 & ember-cli 1.13.8 to S3. Builds in deploy-dist are fine, but on uploading assets the backslashes are not converted to slashes. Thus, in my bucket I have a file named like assets\vendor-94d0c52583a18e95729ebf70f10f3ade.js instead of vendor-94d0c52583a18e95729ebf70f10f3ade.js in the folder assets.
BTW, I am using lightning-pack 0.2.0, which provides ember-cli-deploy-s3 0.1.0.
I've finally got to the bottom of an issue I've been looking at for most of the day - locally my ember lightening fast deploy setup would upload to S3 fine. On our build server however I had a new error:
- SignatureDoesNotMatch: The request signature we calculated does not match the signature you provided. Check your key and signing method.
- SignatureDoesNotMatch: The request signature we calculated does not match the signature you provided. Check your key and signing method.
at Request.extractError (/.../node_modules/ember-cli-deploy-lightning-pack/node_modules/ember-cli-deploy-s3/node_modules/aws-sdk/lib/services/s3.js:524:35)
I now understand that although locally my versions of ember-cli-deploy-lightning-pack and ember-cli-deploy-s3 are the same as my build server's, the ember-cli-deploy-s3/node_modules/aws-sdk version was different.
The build server was using version 2.4.0 and locally with version 2.3.19 - version 2.3.19 uploaded fine, version 2.4.0 did not.
Adding the following to my package.json resolved the issue:
"aws-sdk": "2.3.19"
I don't understand what is causing the error for me in the later version - I did try to inspect upload data and params and could not see anything wrong with the request as suggested in this ST post.
Maybe if others experience, it's worth fixing the version to 2.3.19 or understand what changes are required.
http://docs.aws.amazon.com/AmazonS3/latest/dev/UsingBucket.html#create-bucket-intro
Running ember deploy production results in the following error:
- UnknownEndpoint: Inaccessible host:prosdevlab.s3.oregon.amazonaws.com'. This service may not be available in the Oregon' region.
Since it's outside of US East (N. Virginia), the endpt should resolve to prosdevlab.s3-oregon.amazonaws.com.
I would like to use the endpoint configuration item. Is there a plan for a new tag anytime soon?
For more info: http://stackoverflow.com/a/8622823/614844
I'm now getting signature mismatch issues. I will try to dig in but not a JS developer nor do I have time.
Weirdly some of the files are uploaded successfully according to the logs before it blows up.
+- s3
| - validating config
| - Missing config: fileIgnorePattern, using default: null
| - Missing config: prefix, using default: | - Missing config: `profile`, using default:
| - Missing config: acl, using default: public-read
| - Missing config: cacheControl, using default: max-age=63072000, public, immutable
| - Missing config: expires, using default: Tue Jan 01 2030 00:00:00 GMT+0000 (Coordinated Universal Time)
| - Missing config: dotFolders, using default: false
| - Missing config: batchSize, using default: 0
| - Missing config: defaultMimeType, using default: application/octet-stream
| - Missing config: distDir, using default: [Function]
| - Missing config: distFiles, using default: [Function]
| - Missing config: gzippedFiles, using default: [Function]
| - Missing config: brotliCompressedFiles, using default: [Function]
| - Missing config: manifestPath, using default: [Function]
| - Missing config: uploadClient, using default: [Function]
| - Missing config: s3Client, using default: [Function]
| - config ok
+- upload
| |
| +- s3
| - Using AWS access key id and secret access key from config
| - preparing to upload to S3 bucket REDACTED
| - ✔ review.html
| - ✔ robots.txt
| - ✔ review-6076e4fc0df38aaf34a32042b9f139f7.map
| - ✔ oauth-6586b6d4629b3dff3aed4a0311d667a4.js
| ...
| - ✔ assets/chunk.app.d1f3c4eef12c516036e6.js
| - XAmzContentSHA256Mismatch: The provided 'x-amz-content-sha256' header does not match what was computed.
| - XAmzContentSHA256Mismatch: The provided 'x-amz-content-sha256' header does not match what was computed.
at throwDefaultError (/home/circleci/garaje/node_modules/@smithy/smithy-client/dist-cjs/index.js:838:20)
at /home/circleci/garaje/node_modules/@smithy/smithy-client/dist-cjs/index.js:847:5
at de_CommandError (/home/circleci/garaje/node_modules/@aws-sdk/client-s3/dist-cjs/index.js:4756:14)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
at async /home/circleci/garaje/node_modules/@smithy/middleware-serde/dist-cjs/index.js:35:20
at async /home/circleci/garaje/node_modules/@aws-sdk/middleware-signing/dist-cjs/index.js:225:18
at async /home/circleci/garaje/node_modules/@smithy/middleware-retry/dist-cjs/index.js:320:38
at async /home/circleci/garaje/node_modules/@aws-sdk/middleware-flexible-checksums/dist-cjs/index.js:173:18
at async /home/circleci/garaje/node_modules/@aws-sdk/middleware-sdk-s3/dist-cjs/index.js:97:20
at async /home/circleci/garaje/node_modules/@aws-sdk/middleware-sdk-s3/dist-cjs/index.js:120:14
at async /home/circleci/garaje/node_modules/@aws-sdk/middleware-logger/dist-cjs/index.js:33:22
i.e. "text/css; charset=utf-8" instead of just "text/css"
This downloader for the FastBoot App Server works with AWS S3 to download and unzip the latest version of your deployed application.
fastboot-s3-downloader appears to require files stored in S3 to be zipped but ember-cli-deploy-s3 does not have an option to zip files and then send it to s3. I believe this is true of fastboot-s3-notifier, too. This makes deploying a FastBoot app to S3 using ember-cli-deploy-s3 very tricky.
Is there a way to do this without writing my own ember-cli-deploy plugin?
Also, should I be filing this issue in the FastBoot App Server repo, in this repo, or in the fastboot-s3-notifier + fastboot-s3-downloader repos?
Hi, I am trying to use CDK deploy from the command line and on some default python resources, from https://github.com/aws-samples/aws-cdk-examples.
When I install the dependencies successfully and try deploying, I get the following messages.
One possible reason is a firewall, but I'm not on one. The message is exactly
"Inaccessible host: cloudformation.oregon.amazonaws.com'. This service may not be available in the Oregon' region."
Any ideas how to fix this or work through it?
What do you think about adding web assembly (wasm) files to the list of filePattern defaults? It's fairly well supported in current web browsers.
https://caniuse.com/#feat=wasm
It's easy to configure ENV['s3'] as is. However, I think this change may be worth making because when a request for WASM file fails, it throws some really obscure errors when it tries to read the resulting 404 html as wasm binary. I think it would have thrown my team for a loop if I didn't have an instinct for quirks of our deploy pipeline.
Raising for visibility in case this plugin's maintainers want to investigate their own solutions, or if they can clarify whether any vm2 code is actually reachable using this library. Given the timeframe before PoC disclosure, it might be OK to wait-and-see a few days before taking drastic steps.
vm2: GHSA-cchq-frgv-rjh5 with PoC to be disclosed on August 8vm2 have decided they can no longer justify maintaining the library and have therefore discontinued itember-cli-deploy-s3 depends on proxy-agent which, via a series of libraries under the same monorepo (ending with degenerator), depends on vm2proxy-agent and the other intermediate libs seems to be investigating a solution but the timeline is unclear.Started getting this on Codeship when running ember deploy staging --activate=true
Visit http://ember-cli.com/user-guide/#watchman for more info.
bootstrap-sassy config: some JS loaded [], glyphicons disabled
Error: Cannot find module './lib/aws'
Error: Cannot find module './lib/aws'
at Function.Module._resolveFilename (module.js:325:15)
at Function.Module._load (module.js:276:25)
at Module.require (module.js:353:17)
at require (internal/module.js:12:17)
at Object.<anonymous> (/home/rof/src/github.com/CRaKN/crakn/node_modules/ember-cli-deploy-lightning-pack/node_modules/ember-cli-deploy-s3/node_modules/aws-sdk/index.js:2:18)
at Module._compile (module.js:409:26)
at Object.Module._extensions..js (module.js:416:10)
at Module.load (module.js:343:32)
at Function.Module._load (module.js:300:12)
at Module.require (module.js:353:17)
at require (internal/module.js:12:17)
Here is our packages.json relevant lines:
"devDependencies": {
"active-model-adapter": "2.1.1",
"broccoli-asset-rev": "2.4.2",
"broccoli-funnel": "1.0.1",
"broccoli-merge-trees": "1.1.1",
"broccoli-sass": "0.7.0",
"ember-ajax": "0.7.1",
"ember-buffered-proxy": "0.5.1",
"ember-cli": "~2.4",
"ember-cli-app-version": "1.0.0",
"ember-cli-autoprefixer": "0.6.0",
"ember-cli-babel": "5.1.6",
"ember-cli-bootstrap-sassy": "0.5.3",
"ember-cli-dependency-checker": "1.2.0",
"ember-cli-deploy": "0.6.0",
"ember-cli-deploy-lightning-pack": "0.6.10",
"ember-cli-deprecation-workflow": "^0.2.0",
"ember-cli-dotenv": "1.2.0",
"ember-cli-htmlbars": "1.0.3",
"ember-cli-htmlbars-inline-precompile": "0.3.5",
"ember-cli-ic-ajax": "0.2.4",
"ember-cli-inject-live-reload": "1.4.0",
"ember-cli-mirage": "0.1.13",
"ember-cli-mocha": "0.10.1",
"ember-cli-moment-shim": "1.1.0",
"ember-cli-rails-addon": "~> 0.7.0",
"ember-cli-uglify": "~1.2.0",
"ember-cli-uploader": "^0.3.9",
"ember-composable-helpers": "0.21.1",
"ember-data": "~2.4",
"ember-disable-proxy-controllers": "1.0.1",
"ember-export-application-global": "1.0.5",
"ember-load-initializers": "0.5.1",
"ember-modal-dialog": "0.8.3",
"ember-moment": "6.1.0",
"ember-one-way-controls": "0.5.3",
"ember-resolver": "2.0.3",
"ember-route-action-helper": "0.3.0",
"ember-simple-auth": "1.0.1",
"ember-truth-helpers": "1.2.0",
"ember-validations": "~2.0.0-alpha.4",
"liquid-fire": "0.26.1",
"loader.js": "^4.0.0",
"aws-sdk": "2.7.19"
}
With ember-cli-2.12.0 I am seeing this deprecation warning when running ember commands
DEPRECATION: `ember-cli/ext/promise` is deprecated, use `rsvp` instead. Required here:
Object.<anonymous> (/Users/gordonj/git/ninja-prototype/node_modules/ember-cli-deploy-s3/index.js:4:17)
DEPRECATION: `ember-cli/ext/promise` is deprecated, use `rsvp` instead. Required here:
Object.<anonymous> (/Users/gordonj/git/ninja-prototype/node_modules/ember-cli-deploy-s3/lib/s3.js:7:18)
This is with ember-cli-deploy-s3 0.4.0
HI, great plugins!
I'm just getting started with ember-cli-deploy and am running into some issues in attempting to use the profile configuration. I have an .aws/credentials file that contains 2 sets of credentials: one is [default] and the other is [staging]. The docs led me to believe that I could simply omit accessKeyId and secretAccesskey and instead pass a profile configuration (profile: 'staging'). When I go this route, the default credentials are used. Is this a bug or am I simply misunderstanding how to use profiles?
Thanks!
I have a file that I need uploaded to s3 even if it is already present. The content of the file is changing, but it is not fingerprinted. Since the file is fingerprinted, the file is listed in the manifest, and is present in s3, currently the file does not get uploaded.
I've already forked and added this feature, I can add a PR if this is a feature you'd like to see added to the mainline.
Using version 0.3.1 I keep getting this error:
+- upload
| |
| +- s3
- Using AWS access key id and secret access key from config
- preparing to upload to S3 bucket `nightwatch-staging`
- SignatureDoesNotMatch: The request signature we calculated does not match the signature you provided. Check your key and signing method.
- SignatureDoesNotMatch: The request signature we calculated does not match the signature you provided. Check your key and signing method.
I believe this issue is related to #59, but it doesn't fix it for me. I ran a search of the whole local tree and aws-sdk is pinned to [email protected] - which supposedly remedied the mentioned issue, but I keep getting the SignatureDoesNotMatch error.
Hello. I'm wondering if there is any desire for a PR to add a configuration option allowing you to specify a different endpoint to point the AWS SDK.
My situation is that I'm am developing a deployment script/pipeline locally using minio as a stand-in for AWS, so I need to specify a local url as my endpoint in the s3 config options.
If there is any interest, I'd be happy to open a PR (it's a fairly simple change)
Hi, there is a support Riak S2?
Hello,
recently I've been forced to upgrade to newer version of ember-cli-deploy and a lot of issues started to appear after upgrade:
- RequestTimeout: Your socket connection to the server was not read from or written to within the timeout period. Idle connections will be closed.
- RequestTimeout: Your socket connection to the server was not read from or written to within the timeout period. Idle connections will be closed.
at Request.extractError (/Users/black/Work/<project>/node_modules/aws-sdk/lib/services/s3.js:538:35)
at Request.callListeners (/Users/black/Work/<project>/node_modules/aws-sdk/lib/sequential_executor.js:105:20)
at Request.emit (/Users/black/Work/<project>/node_modules/aws-sdk/lib/sequential_executor.js:77:10)
at Request.emit (/Users/black/Work/<project>/node_modules/aws-sdk/lib/request.js:668:14)
at Request.transition (/Users/black/Work/<project>/node_modules/aws-sdk/lib/request.js:22:10)
at AcceptorStateMachine.runTo (/Users/black/Work/<project>/node_modules/aws-sdk/lib/state_machine.js:14:12)
at /Users/black/Work/<project>/node_modules/aws-sdk/lib/state_machine.js:26:10
at Request.<anonymous> (/Users/black/Work/<project>/node_modules/aws-sdk/lib/request.js:38:9)
at Request.<anonymous> (/Users/black/Work/<project>/node_modules/aws-sdk/lib/request.js:670:12)
at Request.callListeners (/Users/black/Work/<project>/node_modules/aws-sdk/lib/sequential_executor.js:115:18)
at Request.emit (/Users/black/Work/<project>/node_modules/aws-sdk/lib/sequential_executor.js:77:10)
at Request.emit (/Users/black/Work/<project>/node_modules/aws-sdk/lib/request.js:668:14)
at Request.transition (/Users/black/Work/<project>/node_modules/aws-sdk/lib/request.js:22:10)
at AcceptorStateMachine.runTo (/Users/black/Work/<project>/node_modules/aws-sdk/lib/state_machine.js:14:12)
at /Users/black/Work/<project>/node_modules/aws-sdk/lib/state_machine.js:26:10
at Request.<anonymous> (/Users/black/Work/<project>/node_modules/aws-sdk/lib/request.js:38:9)
RequestTimeout: Your socket connection to the server was not read from or written to within the timeout period. Idle connections will be closed.
If I'll be lucky to succeed with the new version (0.5+, latest (0.6.4) to be precise) I think I can write such guide. Otherwise, plugins are the chunks of code that you cannot simply bundle up and run in 5-10mins like, I believe, it should be.
I will be much appreciated if you can take a look at this ticket
@lukemelia
This may be a needlessly specific use-case, in which case we are happy to create a fork, but I thought I would mention it here to gauge interest in a PR.
Our use case is deploying a large app to a dockerized fake-s3 bucket. This plugin issues all uploads at once, which results in hundreds of simultaneous network requests - actual S3 can handle this just fine, but fake-S3 chokes and dies. Performing the uploads iteratively, or in batches, solves the issue.
The proposed PR would pass a config flag toggling batched or all-at-once behavior. If you guys think that is a worthwhile addition to the plugin I will follow up with a PR.
We're currently uploading to S3 via a Grunt plugin. It allows considerable flexibility over the current S3 plugin that I'm interested in seeing if I can get some consensus on. Consider the following example of our setup:
module.exports = function(grunt) {
return {
release: {
files: [
{
cwd: 'dist/assets/',
dest: 'ember/',
expand: true,
src: ['*.css'],
params: {
ContentType: 'text/css; charset=utf8'
}
},
{
cwd: 'dist/assets/',
dest: 'ember/',
expand: true,
src: ['*.js'],
params: {
ContentType: 'application/javascript; charset=utf8'
}
},
{
cwd: 'dist/assets/',
dest: 'ember/',
expand: true,
src: ['*.gz'],
},
{
cwd: 'dist/assets/',
dest: 'ember/assets',
expand: true,
src: ['**/*.!(js|css|gz)', '!assetMap.json', '!failed-*.png', "!passed-*.png"]
}
],
options: {
access: 'public-read',
bucket: '...',
region: '...',
uploadConcurrency: 16,
sslEnabled: true
}
}
};
};Firstly, pattern arrays are supported. This has a few advantages, but what we use it here for is negation. I see from the gzip plugin that support for an ignorePattern option was added, is this how you intend to proceed with other plugins? I see the pattern array with matching left to right as being more powerful and flexible than the current approach, if only because it allows multiple patterns and won't require extra parameters to be passed through promises.
The second thing I see here is that we're able to specify specific content-types and destinations for each pattern group. Is this something you could see a use for?
I've tried to sidestep this problem entirely by hooking a private plugin into the didBuild step, moving the JS/CSS in the <distDir>/assets directory out to the parent directory but alas each Pipeline's returning context is merged with what exists already, meaning you can't delete existing context - in this case I can't delete the <distDir>/assets/*.{js,css} files and later plugins bomb out when they try to access the non-existent files.
I could probably achieve what I desire with a custom upload client but that'd just be private and I'm interested in contributing if there's some agreement, though given the time pressure I'm under I reckon a custom upload client is going to happen anyways 😄
Is there a way to configure S3's cache-control and expires settings (ideally on a per glob basis)?
manifest.txt can be left in an inconsistent state if a deploy is cancelled before all uploads have finished. The problem is that manifest.txt is correctly added to the end of the files to upload (see https://github.com/ember-cli-deploy/ember-cli-deploy-s3/blob/master/lib/s3.js#L81) but this order is not respected since all uploads are fired at the same time (see https://github.com/ember-cli-deploy/ember-cli-deploy-s3/blob/master/lib/s3.js#L32). So if a deploy is cancelled after manifest.txt has been uploaded but before all uploads have finished, the manifest will contain files that have actually not been uploaded. This breaks future deploys.
The solution will be to upload manifest.txt only after all uploads have been completed. I will try to come up with a PR by the end of this week.
Hi,
Can you please list the minimum s3 policy requirements for the plugin to work? Granting ListBucket, GetObject & PutObject does not work - it seems like the plugin needs more permissions?
Hi Team!
I'm updating an Ember CLI Deploy 0.4 app to ^0.5. The app lives in a s3 bucket with the region "US Standard".
What should I put for the region in the config?
TY & Awesome work!
There used to be an option to set cloudfront subdomain key
cloudFrontSubdomain: 'blahblah'
in the s3 options. Did that dissappear? .. does not seem to work anymore
I am using this plug-in for the first time I cannot find a resolution for the error I am seeing below.
tried multiple times always with the same error:
www2.finderscopus.comThis will help avoid very common issues.
I'm not sure how other people use this plugin, but was wondering if it would be a good idea to add support for AWS code deploy in this module?
In my current project, I'm looking at deploying to Amazon cloud and use code deploy to automatically deploy it on EC2 hosts. This s3 deploy plugin already has 80 - 90% of the functionality. The additional functionality that is required:
Looking for ideas, comments and suggestions.
This happened because i specified ember-concurrency/ as my prefix. Whoops.
Can we bump the mime npm package version? The version used in this plugin (1.3.4) does not handle wasm type correctly. I could PR to go to just 1.6, the last release before a major bump, or I can try to figure out 2.x.
The current behavior:
With what appears to be some very recent changes in Chrome, running wasm files in S3 with MIME type application/octet-stream causes a problem when you run the files - an error message about incorrect MIME type and "fallback to array buffer." I've now had to set S3 MIME type to application/wasm by hand after deployment. It's not fatal, because the browser determines a fallback. But it's annoying and I think there's some latency.
Goal
Update mime version so that it works automatically
Whe using the Frankfurt region, I receive the following error when deploying:
- Using AWS access key id and secret access key from config
- preparing to upload to S3 bucket `klubi-si`
- Downloading manifest for differential deploy from `manifest.txt`...
- Manifest not found. Disabling differential deploy.
- InvalidRequest: The authorization mechanism you have provided is not supported. Please use AWS4-HMAC-SHA256.
- InvalidRequest: The authorization mechanism you have provided is not supported. Please use AWS4-HMAC-SHA256.
According to The AWS S3 docs the plugin should specify the v4 specify-signature-version.
Other references:
http://stackoverflow.com/questions/26533245/the-authorization-mechanism-you-have-provided-is-not-supported-please-use-aws4
This plugin should not require accessKeyId and secretAccessKey outright. The default behavior of aws-sdk is to load temporary keys from an IAM Role if one exists. Our deploy tooling runs ember deploy production on an instance running in our VPC with a role and as such should not require a static set of keys.
Hi,
How to prevent favicons and others from being uploaded to s3 ?
My goal is to have /favicon.ico accessible.
Config :
var config = {
...
fingerprint: {
enabled: true,
prepend: "https://some-cloudfront-distribution",
exclude: ['apple-touch-icon', 'favicon', 'mstile', 'android-chrome', 'browserconfig.xml', 'crossdomain.xml']
},
...
};
I see it can use ember-cli-deploy-gzip and maybe I'm just not reading into it enough but what do I actually need to do to get this to upload the gzip file instead of the assets them selves?
I'm planning on using this with codedeploy to roll out these changes across an apache auto scaling group but codedeploy needs to listen on a zip or gzip file.
This would make it the same as https://github.com/ember-cli-deploy/ember-cli-deploy-s3-index
Would that be hard to add?
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.