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

feat: follow best practices with regards to naming .env files #1513

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

Conversation

DrakeEvans
Copy link

Many libraries and dev tools use .env files. Typically different files are used for different environments like dev, staging, and production. Typically, these are named .env.production with the designation happening after the .env.

This change allows sops to recognize dotenv files named with .env at the beginning of the filename in addition to the suffix (current functionality)

Signed-off-by: Drake Evans <31104161+DrakeEvans@users.noreply.github.com>
@DrakeEvans DrakeEvans force-pushed the feat/better-env-file-recognition branch from 59dae62 to 382f421 Compare May 24, 2024 20:17
@felixfontein
Copy link
Contributor

Thanks for your contribution! This is unfortunately a breaking change, see #1450 (comment) for details.

@DrakeEvans
Copy link
Author

@felixfontein I can re-implement as non-breaking by ensuring that the prefix has the lowest precedence when determining filetype.

@felixfontein
Copy link
Contributor

@DrakeEvans it's always a breaking space, since it affects how SOPS identifies the type of some files. It will suddenly use the env store instead of the binary store for some files.

@felixfontein
Copy link
Contributor

(A possible solution would be to embed - if asked to - the original store type in the encrypted file, so SOPS doesn't have to guess it when decrypting. The 'if asked to' part here is important since otherwise it's also breaking backwards compatibility. But that's a more complex change that first needs some discussion...)

@DrakeEvans
Copy link
Author

Yeah Im wondering if its easier to just specify the input-type/output-type in the config file. Does that functionality already exist?

@felixfontein
Copy link
Contributor

I don't think it exists so far.

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.

None yet

2 participants