Recommended way to load a different branch when running tests

[manuelmeurer]

I just migrated from v1 and v2 and I'm using the EnvKey Ruby gem in my Rails app.
With v1, I used dotenv and had .env and .env.test files that contained the ENVKEYs for the development environment and the test sub-environment, respectively.
Now with v2, dotenv is no longer needed and I have a single .envkey file.

What is the recommended way to load the "test" branch when running tests locally?

[danenania]

Hey @manuelmeurer great to hear that you're on v2 now!

I think this should answer your question? - https://docs-v2.envkey.com/docs/branches-and-local-overrides#using-a-branch-in-development

[manuelmeurer]

Thanks! What is the recommended way to do this using the Ruby gem?
The gem loads all env vars using envkey-source and sets them.
Ideally, I'd like to do the same, but load the vars from the "test" branch.
Does envkey-source support branches yet?

[danenania]

Hey @manuelmeurer, you could also accomplish the same by generating a local development ENVKEY for the branch and setting that ENVKEY for your tests. This is what envkey checkout does under the hood.

Passing a local branch name as an argument to envkey-source is an interesting idea as syntax sugar... it would just call out to envkey checkout, but I can see how it could be useful when using Envkey::Core.load_env so you don't have to step outside of ruby.

[manuelmeurer]

Hmm, ok. I generated a local development key for the test branch now and I'm running my tests with ENVKEY=... bundle exec rails spec. This is not ideal of course... would be great if the Ruby gem supported loading a branch at some point!

What's not really clear to me is the difference between server and locals keys for the development environment (and test branch). When would I use a server key for the dev env?

Another small thing I just noticed: the "Integration Quickstart" link that is displayed when a new local key is generated points to https://docs-v2.envkey.com/integration-quickstart which shows a 404, should probably be https://docs-v2.envkey.com/docs/integration-quickstart.

[danenania]

Thanks @manuelmeurer, good catch on the broken docs link. That will be fixed in the next release.

The main differences between servers and local keys are:

• Servers are visible and manageable (can be revoked/regenerated) by any users with sufficient app permissions, while local keys are only visible to the user who generated them.
• Local keys apply local overrides, while server keys do not

So you'd use a development server key for a CI or test server that is shared with your team, while using local keys for local development or running tests locally.

Loading a branch right in an SDK (or envkey-source) is an interesting idea, but is a bit tricky because it would rely on the presence of the CLI, which is typically only installed locally, not on a server.

[matzeeable]

We also would love to see the feature to check out any branch with a generated ENVKEY (regardless of whether it is a Server Key or Local Development Key) with the envkey-source CLI, without creating another ENVKEY for that specific branch.

We have the following scenario:

1. We want that developers in our team to be able to create branches via EnvKey UI
2. The developer checks out the following branch in his Git repository, e.g. git checkout feat/my-feature
3. We have a wrapper on top of envkey-source, and it would be great to pass a --branch argument, e.g. envkey-source --branch feat/my-feature --dot-env. In this case, the developer uses a Local Development Key, and --branch should use the branch of the development environment.
4. The developer modifies the variables in his branch, and commits changes in EnvKey UI as well as in Git
5. In our CI, it would be great to automatically check out the branch the CI job is running. Additionally, it would be nice to "ignore" non-existing branches, e.g. envkey-source --branch feat/my-feature --ignore-missing-branch --dot-env. In this case, the CI uses a Server Key, and --branch should use the branch of the staging environment.

[danenania]

Hey @matzeeable, thanks for the feedback and ideas! Passing an arbitrary branch to envkey-source doesn't play well with the access and encryption model unfortunately, since each ENVKEY is tied to a specific environment and can only be used to decrypt that environment. That said, we will definitely take your thoughts into account and consider ways to make the branch model more useful and developer-friendly.

Also if I'm understanding correctly, you should already be able to do 1-4 using the CLI envkey checkout command. More on this here: https://docs-v2.envkey.com/docs/branches-and-local-overrides -- or is that not what you mean?