Automatic activation of build should not depend on branch

[anilmaurya]

• Staging server deploys staging branch and automatic activation
  will not work if automatic activation only work for master branch

[anilmaurya]

Automatic activating only master make sense when you have only one deploy end point.

In my case we have different server for staging and production, staging server deploy staging branch.

In my opinion automatic activation should not depend on build branch. If you agree then I will change specs accordingly or if you know a better way to solve this problem then please let me know.

Thanks.

[ryanto]

I think this is a good idea. @samselikoff thoughts?

[samselikoff]

Hm, so automatic_activation would apply to every branch? Ideally I'd like to be able to configure which branches automatically deploy. In the case of this PR, even feature branches would automatically deploy (which I wouldn't want).

As a step in the right direction, perhaps we could whitelist master, staging and integration?

[anilmaurya]

@samselikoff Hard coded branch names might create problem in future, may be someone needs to auto_activate branch which is not included in this list.

I think adding option to configure whitelist in application will be good start.

[ryanto]

Another option. We could keep automatic activation to master only, but allow for activation at deploy time on the cli side.

This would be up to the cli client, so Ember would use:

ember deploy:active

I'm not sure I like this, maybe a whitelist of branches is better. Reason I'm not really a fan: it's one more thing you have to do after each deploy. Just wanted to throw out this option.

[samselikoff]

Could also configure in deploy.json

On Mon, Nov 23, 2015 at 6:47 PM, Ryan T notifications@github.com wrote:

Another option. We could keep automatic activation to master only, but
allow for activation at deploy time on the cli side.

This would be up to the cli client, so Ember would use:

ember deploy:active

I'm not sure I like this, maybe a whitelist of branches is better. Reason
I'm not really a fan: it's one more thing you have to do after each deploy.
Just wanted to throw out this option.

—
Reply to this email directly or view it on GitHub
#71 (comment)
.

[anilmaurya]

I liked the idea of configuring deploy.js .

We can add option activate in index

{
  "production": {
    "assets": {
      ....
    },
    "index": {
      "activate": "true" \\ default false
    }
}

We will send activate params to front_end_builds when deploying index. If activate is true then we will set current_build to active_build

Does this sound good plan ?

[anilmaurya]

@samselikoff @ryanto Any update on this ?

tedconf/ember-cli-front-end-builds#25 is also related to this.

[jhirbour]

TED has shifted to React and will no longer maintain this application/library. If you wish to continue using this application/library, please create a pull request and repo ownership can be transferred. This repository will be archived at the end of 2022.