Open Dresdn opened 12 months ago
@henriquebastos - if you're in agreement to support this, I can take some time to update the Readme with the new option.
I was just looking for this! Thanks for contributing @Dresdn I hope this gets accepted soon
@Dresdn thank you for your contribution.
In case of 1
, it would be nice to refactor RepositoryEnv
extending RepositoryString
, but we can do it later.
In case of 2
, maybe RepositoryString
should be RepositoryGoogleManager
or something more descriptive.
Wdyt?
Those are great ideas @henriquebastos, and apologize for being lazy and plopping in the class I used in my project.
For 1
, I was trying not to make it specific to Google since it's a generic format, but looking at other secret managers, they seem to all manage them differently (some have dicts, some return one value at a time). Maybe just renaming it RepositoryGoogleSecretManager
would be best.
For 2
, should we create a BaseRepositoryDict
or something that declares the __contains__()
and __getitem__()
and have RepositoryEnv
and RepositoryGoogleSecretManager
extend that? I'm probably over-thinking it, but the thought process would be other managers that use dicts.
Let me know your thoughts and I'll clean up the PR and add some documentation too.
This should be ready to go @henriquebastos (minus my default editor settings trying to change everything). I ended up just extending RepositoryEnv
and renaming the class to better reflect the purpose.
Original Credit: https://www.codingforentrepreneurs.com/blog/google-secrets-python-decouple-github-actions/
Working with Google Secret Manager, the config is provided back as a string. To support the format, a
RepositoryString
class has been created which parses a string in.env
format.