Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Automatic activation of build should not depend on branch #71

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

anilmaurya
Copy link
Contributor

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

- Staging server deploys staging branch and automatic activation
will not work if automatic activation only work for master branch
@anilmaurya
Copy link
Contributor Author

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
Copy link
Contributor

ryanto commented Nov 22, 2015

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

@samselikoff
Copy link
Contributor

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
Copy link
Contributor Author

@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
Copy link
Contributor

ryanto commented Nov 23, 2015

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
Copy link
Contributor

Could also configure in deploy.json

On Mon, Nov 23, 2015 at 6:47 PM, Ryan T [email protected] 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
Copy link
Contributor Author

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
Copy link
Contributor Author

@samselikoff @ryanto Any update on this ?

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

@jhirbour
Copy link
Contributor

jhirbour commented Feb 1, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants