The logic is already here, would be great if we could deploy the whole site to amazon. Sometimes I do this at the beginning of a project just for prototyping.

We deploy several environments for our app. They are configured within config/environment.js.

Currently the ember-deploy script is explicit about building the application with the production environment.

See: https://github.com/LevelbossMike/ember-deploy/blob/master/lib/commands/deploy.js#L22

This has the side-effect of not respecting all the env vars that my application needs to be aware of for each environment. e.g. apiHost, websocketHost, googleAnalyticsId, etc.

I considered adding these configurations to the deploy.json, but it seems a little out of the scope of that files purpose, or require a refactor that ends up conflating my application configuration with the deploy process.

Thoughts?

• Green build
• Update changelog
• Update version in package.json
• Tag
• Publish to npm

solved as described in mgutz/execSync#24 (comment) - But only after installation, for that installation instance only. This is also affecting ember-cli-deploy for Windows

as I think I'm one of the few (the only?) contributor here with Windows, I'll try and take ownership of this as well - just posting this issue to have something to refer to / some discussion points

execSync is used for executing git tagging only - before ember-deploy had a dependency on gitty (iirc) (which was also problematic under Windows). So, maybe

• consider alternative ways for getting the git version tag
• consider alternatives to execSync (for example sync-exec)
• use io.js and node.js v0.12 execSync

Most likely we can do some 0.12+ detection, then otherwise require sync-exec.

Thought that maybe it might be a good idea to add a post install message for this version that basically says "Things have changed. If you are upgrading from achambers/ember-cli-deploy then follow the migration instructions at ".

One of my concerns is separating the task of deploying and developing. This breaks down into a couple things:

1. Making new builds available
2. Deploying new builds.

I'd like our deploy process to look like this:

1. Update source control (either tag a new release, or push new code, whatever)
2. Deploy team is notified of new build available (or polls for new builds)
   • This is unimportant, but Github webhook, or cron job on deploy servers are both trivial to implement)
3. Deploy team opens up web UI, sees available builds and clicks a button for the build they want to deploy (for whatever target, e.g. staging, prod, etc).

I can see this web UI as an addon/plugin based on @lukemelia's talk at EmberConf2015, but wanted to get thoughts on the use case.

Not sure exactly how this would work yet, but it would be awesome. It would be cool to print this upon install of this addon, too.

First time I tried deploy:assets, program hung on "Uploading assets..."

This is really an execSync error (issue mgutz/execSync#27), but it affects ember-cli-deploy. Maybe an alternative package could be used to resolve this issue or the issue could be resolved upstream.

Cannot find module './build/Release/shell'
Error: Cannot find module './build/Release/shell'
    at Function.Module._resolveFilename (module.js:338:15)
    at Function.Module._load (module.js:280:25)
    at Module.require (module.js:364:17)
    at require (module.js:380:17)
    at Object.<anonymous> (/myrepo/ember/node_modules/ember-cli-deploy/node_modules/execSync/index.js:30:11)
    at Module._compile (module.js:456:26)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Module.require (module.js:364:17)

I don't know the policy for listing issues with upstream packages. Feel free to close this if it's not appropriate as an ember-cli-deploy issue.

Let's create a document that specifies the architecture decisions around plugins and how they should be developed. This could be a markdown file in the root of the app, maybe called DEVELOPING_PLUGINS.md or PLUGIN_ARCHITECTURE.md.

A good place to get inspiration for this is ember-cli/ADDON_HOOKS.md and ember-cli/ARCHITECTURE.md

Users who are using version 0.0.6 will most likely get the upgrade of 0.4.0 automatically due to referencing ^0.0.6.

In order to prevent users from breaking when we publish 0.4.0, the following issues would need to be addressed.

• Include an s3 plugin by default (this should only work or be registered if we detect someone using preZeroFourZero)
• Shim adapter loading to support the loading of https://github.com/achambers/ember-cli-deploy-redis-index-adapter
• Shim the config from 0.0.6 to support the old config structure
• Add feature detection based on config location (or other option?) to identify preZeroFourZero users
• ensure the following command flow works properly ember build && ember deploy:index && ember deploy:assets && ember activate <version> && ember deploy:versions

I think I've captured all the details here as a starting point for discussion. Please include any other thoughts and opinions on this.

Deployment pipeline

We can look at deploys are a series of steps that change the state of our production application. Our plan is to provide hooks that represent the common steps that you would find in the deployment lifecycle of an Ember application. Deploy adapters will be able to hook onto one or more of the pipeline steps to add functionality to the deploy.

Proposed steps

1. willDeploy
2. build
3. update
4. activate
5. didDeploy

Questions / comments:

• Is it worth providing an API for adding a step?

Hooks

Adapters will register themselves with one or more of the hooks to provide functionality. Registration is done by having a function named deployHookName on the adapter object.

S3Adapter = {
  deployAssets: function(deploy) {
    var results = this.uploadAssets();
    ...
  }
}

Edited to match luke's comment below.

Questions / comments

• Does order matter? If I register two adapters to build hook is there a situation where I need to control which gets run first?

Default adapters

By default ember-cli-deploy will ship with a BuildDistAdapter that hooks into the build step. This runs ember build. It's a good example of a simple adapter + hook, 99% of people will use it, and it easy to override if you need different build-to-dist functionality.

Questions / comments:

• Does this mean we need to provide an API for removing adapters from hooks?

Shared state and deploy metadata

Adapters may want to share data with other adapters that may run later in the lifecycle. For example a post-deploy adapter may want to summarize all the work done by your build, asset, and index adapters.

There will be an API to read the return values from other adapters. Consider it unstable and not encouraged, but it will be there to see if this is something useful to provide. If we notice of pattern of adapters sharing information we can hopefully provide a shiny API.

For users of the former ember-cli-deploy project that have upgraded to the new version without being aware of the changes, we should add some deprecation warnings for when they run commands from the former project that no longer exist in this new one.

The commands that will print deprecation warnings are:

• ember deploy:assets
• ember deploy:index
• ember activate
• ember deploy:versions

Just created a new bucket with the Frankfurt region and getting this error message when trying to deploy:

Unable to sync: InvalidRequest: The authorization mechanism you have provided is not supported. Please use AWS4-HMAC-SHA256.
    at Request.extractError (/frontend/node_modules/ember-deploy/node_modules/s3/node_modules/aws-sdk/lib/services/s3.js:343:35)
    at Request.callListeners (/frontend/node_modules/ember-deploy/node_modules/s3/node_modules/aws-sdk/lib/sequential_executor.js:100:18)
    at Request.emit (/frontend/node_modules/ember-deploy/node_modules/s3/node_modules/aws-sdk/lib/sequential_executor.js:77:10)
    at Request.emit (/frontend/node_modules/ember-deploy/node_modules/s3/node_modules/aws-sdk/lib/request.js:604:14)
    at Request.transition (/frontend/node_modules/ember-deploy/node_modules/s3/node_modules/aws-sdk/lib/request.js:21:12)
    at AcceptorStateMachine.runTo (/frontend/node_modules/ember-deploy/node_modules/s3/node_modules/aws-sdk/lib/state_machine.js:14:12)
    at /frontend/node_modules/ember-deploy/node_modules/s3/node_modules/aws-sdk/lib/state_machine.js:26:10
    at Request.<anonymous> (/frontend/node_modules/ember-deploy/node_modules/s3/node_modules/aws-sdk/lib/request.js:22:9)
    at Request.<anonymous> (/frontend/node_modules/ember-deploy/node_modules/s3/node_modules/aws-sdk/lib/request.js:606:12)
    at Request.callListeners (/frontend/node_modules/ember-deploy/node_modules/s3/node_modules/aws-sdk/lib/sequential_executor.js:104:18)

Everything worked fine when I was using Oregon as bucket region.

Since moving ember-deploy to ember-cli/ember-cli-deploy we need to update the README. It probably needs quite an overhaul but below are a few of the things mentioned in Slack.

• Change references to ember-deploy and LevelBossMike
• De-emphasise references to Luke's 'Lightening Deployments' presentation
• Add something to the top of the README to briefly explain the migration that has happened and why users of the former ember-cli-deploy will probably be experiencing issues.

Existing Plugins

• ember-deploy-redis, index-adapter for Redis
• ember-deploy-s3, assets-adapter for AWS S3
• ember-deploy-s3-index, index-adapter for AWS S3
• ember-deploy-azure, index-adapter and assets-adapter for Azure Tables & Blob Storage respectively

I can't use third party servers. It would be awesome if I could use this addon to put my static assets anywhere (instead of just an AWS bucket.

Not sure how things work internally, but I'm guessing swapping out the assets module could be swapped out and the API could either be standardized or a new API could be created for the config file.

Just wanted to ping about ember-cli-deploy to make sure we're sharing as much work as possible. Are there some fundamental differences to your approach?

I'm using the ember-cli-dotenv package. Has anyone had any luck with including environment variables in to the deploy.js file?

i've tried everything from process.env.S3_SECRET_KEY to ENV.APP['S3_SECRET_KEY]`

I know there is buildEnv for the deployment config. I think it would make sense to default buildEnv to the --target option being provided.

Does this change make sense or am I missing a common usage?

I can create a PR if this is a reasonable change

I'm wondering if ember-cli/ember-deploy knowing about your backend (redis username/pw) is an antipattern.

What if ember-deploy was more generic, and just "pinged" the back-end (e.g. HTTP request), letting it know there's a new build available at a certain path (e.g. S3 path)? Then, the back-end would be responsible for updating the data store.

This is needed for addons that bring their own assets via their public folder because they will be build into dist/<addon-name>

resulting into a dist folder that looks like this:

dist
├── assets
│   ├── <my-app>-2c49c3c4046c04ea94f297df85b4f9c6.css
│   ├── <my-app>-345a54d9732ac3632a0eda5915931e8d.js
│   ├── vendor-cafaa3ab9ca7ecae85dd3ffe1e439903.js
│   └── vendor-d41d8cd98f00b204e9800998ecf8427e.css
├── crossdomain.xml
├── <some-addon>
│   └── assets
├── <some-other-addon>
│   ├── assets
├── index.html
└── robots.txt

• Confirm build works
• Update build badge in README

While attempting to install using node 0.11.16, npm 2.4.

→ node -p process.versions
{ http_parser: '2.3',
  node: '0.11.16',
  v8: '3.28.73',
  uv: '1.0.2',
  zlib: '1.2.8',
  modules: '14',
  openssl: '1.0.1l' }

→ npm --version
2.4.1

→ ember install:addon ember-deploy
version: 0.1.12
Installing packages for tooling via npm..[execsync v1.0.2] Attempting to compile native extensions.
Installing packages for tooling via npm[execSync v1.0.2]
    Native code compile failed!!
Installed packages for tooling via npm.
Installed addon package.

• Check for signs that the user might have been using the former ember-cli-deploy and warn them. (You can get a good idea by checking to see where the config is stored.)

For 0.4.0 we want to support any previous commands. Therefore we should revert #56 .

I think it is not really desirable to store credentials to your bucket on disc. They could by accident be committed and exposed. A common solution is to store them in an environment variable.

Node can access environment variables through process.env. You could use the same approach as ember cli has taken for their config/environments.js. By exporting a function rather then an object you can use the environment variables.

Background

I'm trying to develop an ember-cli-deploy activation add-on that works with pass-through caching layers like Varnish. Varnish, unlike Redis, has no way to actively insert index.html. Instead

• adapter.upload uploads index-295d1e4a.html to the Assets server (e.g. S3)
• adapter.setCurrent does three things:
  • overwrite a "symlink" object to the Assets server. This is an empty file called current-version that has an HTTP header like X-Ember-Current-Version: 295d1e4a
  • purges /current-version in Varnish
  • purges /index.html in Varnish

The next time someone requests /index.html from Varnish, it will make an upstream request to S3 for /current-version, parse the header, and turn the request for /index.html into one for /index-295d1e4a.html

Similarly, listVersions would ask the asset store for -- essentially -- ls index-*.html.

Request

This sort of workflow relies on three changes to the current API:

1. Inject the asset uploader into the index adapter
2. Asset stores have a public API to upload single file
3. Asset stores have a public API to list files

That feels like a lot to change in the current ecosystem. The only alternatives I see are

1. ember-cli-deploy-varnish index-adapter understands all of the various ways of storing assets
2. ember-cli-deploy-varnish index-adapter requires the client application to configure complex upload and query operations

Does anyone else have other suggestions?

I just ran npm install ember-cli-deploy --save-dev.

When trying to run ember serve or ember deploy with ember-cli-deploy 0.4.0, ember complains about the following:

Cannot find module 'glob'
Error: Cannot find module 'glob'
    at Function.Module._resolveFilename (module.js:338:15)
    at Function.Module._load (module.js:280:25)
    at Module.require (module.js:364:17)
    at require (module.js:380:17)
    at Object.<anonymous> (/Users/walti/Projects/distillery/node_modules/ember-cli-deploy/lib/utilities/detect-deprecated-config.js:2:12)
    at Module._compile (module.js:456:26)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Module.require (module.js:364:17)

It seems that the glob dependency is not installing automatically. If I do a npm install --save-dev glob in my ember directory, it then works.

How does one fix this?

It would be really great if ember-cli-deploy supported different deploy types, other than just deploying the index.html file.

For most apps, there are usually three things that change in the index.html file between deploys. For my app, it's

app-<hash>.js
app-<hash>.css
vendor-<hash>.js

And the rest of the index.html page always stays the same.

Use Case

We insert dynamic content into our index.html on each request. For instance, we use node-geoip to make a best guess at the user's location and insert it into the rendered index.html for Ember to read out. You can imagine other cases where one might want to modify the HTML before serving to the user (user specific api token, etc.)

With the current implementation, we have to deploy the entire index.html file with a marker (like an HTML comment) to know where to insert our dynamic content.

<head>
  ...
  <link rel="stylesheet" href="//app-abc1234.css">
  <!-- Insert server data below -->
</head>

Then we have to locate this comment, remove it and insert our data.

Feature Request

It would be great if ember-cli-deploy could be configured such that Redis could store just the hashes of the files that change between deploys. This way, we could leave the construction of the (very) simple index.html file to the server and more easily control where we insert our dynamic server data.

Unless my config option for the s3 bucket is a root bucket, i.e.- assets I get this error:

Built project successfully. Stored in "dist/".
Uploading assets...
Unable to sync: NoSuchKey: The specified key does not exist.

I'd like to be able to pass a path to my bucket. i.e.-

bucket: 'apps-assets/<my-app-name>/development'

Currently we do something like

var app = new EmberApp({
  fingerprint: {
    prepend: 'https://s3.amazonaws.com/our.bucket.name/'
  }
});

This feels like it should live in ember-deploy land rather than Brocfile.

1. Is it possible to add the fingerprint.prepend option during a build?
2. Is this something we could add to deploy.json? Perhaps as an assetPrefix key? (In case someone's uploading to S3 but serving from Cloudfront).

Considering people may be storing sensitive credentials there. d064933

I noticed there are still quite a few references to ember-deploy in the project including places like index.js which is used when a user runs ember help. We should rename these.

I just read this article by @Kerry350 and it mentioned adding fingerprint.prepend to get the files prepended with the cdn url. Whilst I know this isn't technically part of ember-cli-deploy it would be nice to put a note in the documentation.

It would be nice to have a config option to automatically activate a new index.html whenever it is deployed. Would that be the kind of thing that should be an option in ember-cli-deploy itself, or should that be an add-on of some sort?

When attempting to upload static assets to S3, I receive the ECONNREFUSED error.
Here's what it looks like:

→ ember deploy:assets --environment staging 
version: 0.1.11
Uploading assets...
Unable to sync: Error: connect ECONNREFUSED
    at errnoException (net.js:905:11)
    at Object.afterConnect [as oncomplete] (net.js:896:19)

My deploy.json looks about like this:

{
  "staging": {
    "buildEnv": "staging",
    "store": {
      "host": "redacted.test",
      "port": 49155,
      "password": "XXX"
    },
    "assets": {
      "type": "s3",
      "gzip": true,
      "accessKeyId": "AAAAAAAAAAAAAAAAAAAA",
      "secretAccessKey": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
      "endpoint": "redacted.text.s3-website-us-west-1.amazonaws.com",
      "bucket": "redacted.test"
    }
  }
}

I tried multiple IAM accounts, and double-checked my S3 user policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:ListBucket"],
      "Resource": ["arn:aws:s3:::redacted.test"]
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:GetObject",
        "s3:DeleteObject"
      ],
      "Resource": ["arn:aws:s3:::redacted.test/*"]
    }
  ]
}

And bucket policy:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Allow Public Access to All Objects",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::redacted.test/*"
        }
    ]
}

Hi, I'm planning to in the near future write an adapter for Azure, their CDN & their key/value store. What's the preferred way of releasing it to the greater public, too? Shall I contribute to this project or create a separate add-on? If the latter is preferred, would you want to maintain a list of existing OSS add-ons?

I wrote a PR for ember-cli-deploy-s3-index that displays extended information when running deploy:list in a few ways:

1. If the verbose config value is set, it looks up the related git sha and displays the git log information.
2. It uses a url config value so the url to access a given revision can be generated and displayed next to the revision tag.
3. It added the ability to display which revision was currently active.

All of these things had to be done in the index-adapter, because ember-cli-deploy leaves the display of revisions up to the index adapter. There's some discussion on the PR and also in a separate issue about moving some of the intelligence into ember-cli-deploy.

In order to make these sort of changes work, we'd need to:

• move printing the list of revisions into ember-cli-deploy, and require the index-adapters to return a list/object of revisions, somehow marking which is current. (or responding to an additional method)
• Add a method to the taggingAdapters that respond with extended information, if available.

One of the other features I discussed was allowing deploy:activate to be called without arguments to activate the most recent revision or also to be called with just the number displayed next to the revision key.

$ ember deploy:list 
version: 0.1.15
Found the following revisions: 

1) my-app:5a77e50 
2) my-app:b8256de 
3) my-app:c239613  

Use activate() to activate one of these revisions

$ ember deploy:activate 
# would activate my-app:5a77e50

$ ember deploy:activate 2
# would activate  my-app:b8256de

I'm moving the discussion over here so we can figure out where some of these changes belong.

Currently, with configuring gzip extensions, both ember-deploy and (in my case) ember-deploy-azure have to check config.assets.gzipExtensions ? config.assets.gzipExtensions : ['js', 'css', 'svg'].

It would be much cleaner and less prone to error (e.g. for when ember-deploy changes something in its default settings and an old ember-deploy-addon is not updated) to have ember-deploy augment the configuration file with default settings and passing that on to underlying deploy-addons. Possibly ideally in the configuration reader.

As I don't have a clear picture of which implications it has for existing infrastructure, just thought I'd open an issue to get some feedback first.

When ember-cli runs ember install:addon ember-cli-deploy, a blueprint should run to output a starter config/deploy.js file. The file should have some commented examples showing users how switch based on deploy environment, how to use environment variables, and execute a command synchronously to get a value.

IndexAdapter.upload gets a buffer and not the Index HTML: http://nodejs.org/api/fs.html#fs_fs_readfile_filename_options_callback
This doesn't have to be a problem, but either the functionality should be updated, or the README.

• Update README
• Add deprecation warning in case of deploy.json being used

via @danshultz "Just noticed the following when testing - it appears that encapsulating the defaults (d838cd7) seems to cause a breakage here --> https://github.com/ember-cli/ember-cli-deploy/blob/master/lib/tasks/assets.js#L59"

I have nginx installed with the HTTP_REDIS module so it would be advantageous to have nginx serve the index.html file. However the nginx redis module is very limited. It is not easy to lookup the key and then use the key to fetch the content.

I am thinking a improved approach would be to copy the index content to the value of the current key thus eliminated the need for a lookup.

The second thing I ran into was wanting to store the html cache.manifest file in redis as well. I know cache.manifest is a bastard, but it does help with mobile.

Just wanted to run this by the team. I will most likely fork the ember-deploy-redis repo and implement this functionality.

🍻 to paving the cow paths.

Here is the nginx config; quite simple.

map $arg_version $app_version {
    default "current";
    ~^\w+ $arg_version;
}
upstream redisbackend{
    server 127.0.0.1:6379;
}
server {
    location / {
        set $redis_key my-app:$app_version;
        redis_pass redisbackend;
        default_type text/html;
    }
}

Existing Plugins

• ember-deploy-redis, index-adapter for Redis
• ember-deploy-s3, assets-adapter for AWS S3
• ember-deploy-s3-index, index-adapter for AWS S3
• ember-deploy-azure, index-adapter and assets-adapter for Azure Tables & Blob Storage respectively