Offer possibility to use sql-migrate cli with env vars instead of file conf

[jdelobel]

Is it possible to to use sql-migrate cli with env vars instead of file conf?

[paulwalker]

It seems a bit strange that the migrations can be accessed via bindata, but then a config file is still required?

[rubenv]

@paulwalker please open a different issue when asking a different question.

[sbrudz]

I was able to use environment variables within the dbconfig.yml file:

development:
    dialect: mysql
    datasource: ${DBUSER}:${DBPASS}@tcp(${DBHOST}:${DBPORT})/${DBNAME}?parseTime=true
    dir: migrations
    table: migrations

[risentveber]

Add docs to readme for this in #143 @rubenv @sbrudz

[chakrit]

@sbrudz @risentveber That is not the same as using env vars directly. See the Factor III. in Twelve Factor App.

Quoting:

Another approach to config is the use of config files which are not checked into revision control, such as config/database.yml in Rails. This is a huge improvement over using constants which are checked into the code repo, but still has weaknesses: it’s easy to mistakenly check in a config file to the repo; there is a tendency for config files to be scattered about in different places and different formats, making it hard to see and manage all the config in one place. Further, these formats tend to be language- or framework-specific.

Emphasis mine.

Personally environment variables are better because it's much easier to set with tools like the shell scripts, docker env vars, kubernetes manifest, heroku settings page etc. Requiring there to be a file on disk creates a dependency on the file system, meaning for each place we deploy (container image, prod servers, staging servers etc.) we need to add code to place this file at the right place and at the right time before things will actually work.

This also prevent deploying a standalone fat Go binary with everything inside it. Which is one of the main advantages of using Go in the first place.

[rubenv]

The CLI is really just intended as a utility during development. For any serious deployment (especially 12 factor things), I always recommend using sql-migrate as a library and embedding migrations (e.g. with packr).

On Sun, Sep 29, 2019, 06:29 Chakrit Wichian notifications@github.com wrote:

@sbrudz https://github.com/sbrudz @risentveber https://github.com/risentveber That is not the same as using env vars directly. See the Factor III. in Twelve Factor App https://12factor.net/config.

Quoting:

Another approach to config is the use of config files which are not checked into revision control, such as config/database.yml in Rails. This is a huge improvement over using constants which are checked into the code repo, but still has weaknesses: it’s easy to mistakenly check in a config file to the repo; there is a tendency for config files to be scattered about in different places and different formats, making it hard to see and manage all the config in one place. Further, these formats tend to be language- or framework-specific.

Emphasis mine.

Personally environment variables are better because it's much easier to set with tools like the shell scripts, docker env vars, kubernetes manifest, heroku settings page etc. Requiring there to be a file on disk creates a dependency on the file system, meaning for each place we deploy (container image, prod servers, staging servers etc.) we need to add code to place this file at the right place and at the right time before things will actually work.

This also prevent deploying a standalone fat Go binary with everything inside it. Which is one the main advantages of using Go in the first place.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/rubenv/sql-migrate/issues/82?email_source=notifications&email_token=AAAKPGCPRRH36XBRHX37AK3QMAVKHA5CNFSM4DPU3GEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD73H44A#issuecomment-536247920, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAKPGGS3M3VCI2U53CQH3TQMAVKHANCNFSM4DPU3GEA .

[chakrit]

@rubenv ah ok, thanks for clarifying. so the primary use case is actually to embed and roll our own cmds.