Is there any way to use dotenv with Bitbucket Pipelines?

[jmbrandheroes]

As the title says, is there any way to use dotenv with Bitbucket Pipelines for CI purposes, while still adding the (perhaps multiple) `(.stage).env` to .gitignore?

I know Pipeline supports environment variables, and that they can be referenced in bitbucket-pipelines.yml, but I can't figure out how to use `dotenv` files instead, and vary which file to use based on i.e. branch patterns.

For example, I'd like commits to `develop` to use `.test.env` variables, while commits to `master` instead uses the variables from `.prod.env`.

Perhaps I'm going down the wrong path? Although other websites use examples of multiple `.env` files, the library authors discourage that approach. I'm using Zeit Now for hosting, so I can't just SSH a `.env` file onto the server.

Any advice is very welcome :-)

(also asked on SO, see here for points)

[Graham Gatus · Accepted solution]

Short of storing multiple environment files inside your repository, I like the approach mentioned in the stack overflow response of using a base64 encoded environment variables to store each file.

You could configure multiple environment variables containing the base64 encoded .env file, one per environment. The current branch is exposed via the 'BITBUCKET_BRANCH' variable, so you could use that in combination with the per environment .env variables.

Alternatively, storing the .env files in a separate git repo would also work - you could then clone the repo as part of your pipeline, and select the correct .env file to use based on BITBUCKET_BRANCH.

[TimorKalerman]

Correct me if I am wrong but if you encode the .env files (base64), each time you want to change it like adding a new KEY=VALUE, you will need to encode the file again and store it again.

This approach looks like unfriendly and time consuming.

The other suggestion requires you to maintain 2 repositories for instead of 1 which is also complicate things.

Do you have another suggestion that is both user-friendly and simple?

[jmbrandheroes]

Security always comes at the cost of convenience @TimorKalerman  :-) I find the base64 way to be the most sensible and easy enough to work with.

[tobias_eisenschenk]

Hi @jmbrandheroes 

I think the typical setup would be to use `.env` files as a convenience for your local environment. However on a CI server / build container you wouldn't want your `.env` file to sit around (dont take my word). Instead you could use some mechanism your cloud provider exposes to pass variables. Depends on your vendor, but if it is plain node it could look like `MY_VAR=$MY_VAR node myscript.js`. And if that gets too verbose you could do this is your pipelines.yml:

script:
  - MY_VAR_GROUP="MY_VAR1=$MY_VAR1 MY_VAR2=$MY_VAR2"
  - $MY_VAR_GROUP node myscript.js

[jmbrandheroes]

Valid, but impractical for more than a handful of secrets IMO. 

And no, you don't want your .env file in neither the repo nor the CI server, but a base64 encoded string representation of it as a container variable is, in my opinion, both a safe and pretty easy way of doing it.