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

First Push Only Options #4

Open
crisward opened this issue Jul 7, 2016 · 4 comments
Open

First Push Only Options #4

crisward opened this issue Jul 7, 2016 · 4 comments
Labels
enhancement on hold May revisit in the future

Comments

@crisward
Copy link
Owner

crisward commented Jul 7, 2016

It would be good to enable some options to only apply on first push / or perhaps if they don't already exist. (as per discussion here dokku/dokku#2269)

Env vars are mentioned as an issue, but dokku-require doesn't specifically support env vars. However having a 'firstpush' option could be useful in general.

Dokku may add something to core for this, but here could be a good place to experiment with the feature.

eg.

"dokku":{
    "plugins":[
      {
        "name":"mariadb",
        "firstpush":true,
        "commands":["mariadb:create mydb","mariadb:link mydb $APP"]
      }
    ]
  }
@josegonzalez
Copy link
Contributor

Or better would be something like phase?

@crisward
Copy link
Owner Author

crisward commented Jul 7, 2016

What options would you have under phase?

@notpushkin
Copy link

I think it makes sense to make "firstpush": true the default option. Are there even any cases when recreating a plugin on each push is a desired behaviour?

@crisward
Copy link
Owner Author

crisward commented Mar 6, 2017

Just to clarify, it never 'recreates' a plugin if it already exists. So if you have postgres setup and linked, it will not add it the second time. But if you delete your database and repush, it will then recreate it. I personally find this useful as the ability to wipe and re-push during development can be very useful.

The attempted re-create of plugins doesn't really take any significant time so I think I'm going to leave this for now. I'll revisit this if it seems necessary in the future.

@crisward crisward added the on hold May revisit in the future label Sep 15, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement on hold May revisit in the future
Projects
None yet
Development

No branches or pull requests

3 participants