Support new cloudfront feature to deploy to a subfolder in s3

[BryanCrotaz]

I want to deploy only through s3/cloudfront, with a folder per branch. So I'd like to deploy both index and assets to this folder (creating it if necessary) , then setup a cloudfront distribution pointed at this folder.

It feels as though this requires a more flexible configuration, possibly through a config file which defines the steps to be carried out:

The current config could be stated as

deploy: [
  {
    task: "deploy",
    assets: true,
    s3: {
      bucket: "abc",
      path: "/" 
    }
  },
  {
    task: "deploy",
    index: true,
    redis: {
      // redis config here
    }
  },
  {
    task: "configure"
    redis: {
      currentIndex: "my-latest-index"
    }
  }
]

The array sets the task ordering and is easily extensible. I suggest that in the above example we register tasks with the container:
deploy:s3
deploy:heroku
configure:heroku

Thoughts?

[achambers]

Interesting mate. Happy to chat through this. I'm overseas at the moment. Back in just over a week so I should be able to spend some time to give it some thought then.

[BryanCrotaz]

This might also solve [#65] by allowing explicit choice of adapters.

[BryanCrotaz]

In my case my config would look like this:

deploy: [
  {
    task: "deploy",
    index: true,
    assets: true,
    s3: {
      bucket: "abc",
      path: "/",
      headers: [
        {
          name: "cache-control",
          value: "public,max-age=10"
        }
      ] 
    }
  },
  {
    task: "configure"
    cloudfront: {
      // some cloudfront config here to point at my bucket
    }
  },
  {
    task: "configure"
    route53: {
      // setup a DNS subdomain for my branch here
    }
  }
]

[BryanCrotaz]

Meet up at the Ember London project night and do some thinking together?

[achambers]

I'm not yet convinced about the configuring of cloudfront you speak of. That seems very specific to your particular use case and I'm still trying to work out how far this tool is supposed to go. It's meant to be quick and simple. Not have loads of config to cater for every possible use case. Not convinced this is something to focus on right now.

The ability to write custom adapters makes it flexible enough for users to deploy to different places other than redis and S3 (asset customer adapters is still in progress). I'm still yet to see a massive need for more than that as yet.

Not convinced this is the place to be spending the effort right now.

[BryanCrotaz]

I don't think the core product should deploy to cloudfront, but the core product cannot be extended by a user to do that today.

All I think we need to do is change the architecture slightly to have a config where you list tasks (equivalent to adapters) in a specified order, instead of auto detecting. The auto detect cannot cope when multiple adapters are installed - it doesn't know what to do about that.

I've met with 3 different devs at ember london who agree that this would be a useful refactoring that would enable them to solve their own specific deployment issues by making their own tasks to plug in.

Those tasks could then be shipped as new addons, and referenced in the ember-cli-deploy config file.

If we have two type of task, deploy (rename of adapter), and configure (setting current key in redis for example), then each new task can have its own configuration object schema, so the core product doesn't need to plan for cloudfront etc. I can't think of a deploy task that couldn't be described by configure or deploy.