Add a feature to only build for a selected environment

[nishchal-v]

We can build for selected flavour using
arkana --flavour snowflake

It would be nice to have feature like
arkana --environment Production

So that we don't need to have every environment keys in our CI and we can just load only production keys in CI and that would be enough to run Arkana on CI

[rogerluan]

Interesting idea @nishchal-v , thanks for contributing!

Just wondering, you don't build your project in CI in non-prod envs (like in PRs, or in the main branch)?

[nishchal-v]

@rogerluan yes i do build other environments as well.

This specific scenario can come in handy where you have dedicated setup for only prod environment and you don't want to load every environment secret.

[rogerluan]

Makes sense! 👍
I'll keep this one open, feel free to contribute with a PR if you have the chance 😃 I won't have availability to work on this anytime soon, but should be a simple change!

[dalewking]

I would like this as well. In my case we have debug and release builds that have different OAuth credentials. On a local developer machine they should not be able to build release configurations. We only build release configurations in CI environment which provides the environment variables for release.

My workaround will essentially be to define 2 different yaml files. The one ran on developer machines only has:

environments:
  - Debug

and .arkana-release.yml has:

environments:
  - Debug
  - Release

[rogerluan]

Nice solution @dalewking ! 💪 good to see that this has a workaround while it doesn't get implemented.

I'm open to discussing how you guys feel like this should be implemented, from a DevX PoV, architectural, etc. I don't have an opinion yet

[nishchal-v]

The workaround suggested by @dalewking would require to manage multiple .arkana.yml for different environments.

Having the capability of selecting the environment while running arkana is the best way to go, i think.

[dalewking]

That is why I labeled it a workaround, not a solution. It works but not ideal to have different yaml files that only differ in targets.

[nishchal-v]

Yes, i understand that.
I was just commenting to put some weightage on not relying upon a workaround and going with the actual solution 😄

[rogerluan]

@nishchal-v @dalewking I've opened a PR for this here: #48

Would you be so kind and review it? Possibly test it? See if I missed anything, if you'd change anything in the design, etc :) Looking forward to your feedback! I hope this improves your projects without the necessity to keep multiple config files around 🤗

Cheers!

[nishchal-v]

Wow, thank you so much for including the feature 🙏🏼.

Regarding the review of the PR, I am unaware of the Ruby development so it would be best if someone who understands the Ruby and it's coding standards review it.

Regarding the testing of the PR, I have tested it for environment selection and it works as intended. Thanks again for including this feature.
I also have added a suggestion in the PR comments, see if we can make that change else current changes would do just fine.

[nishchal-v]

Btw, waiting for the Android projects support 😅.
This tool is very helpful from security standpoint for iOS projects, thanks for providing such open-source tool 🙏🏼

[rogerluan]

Glad you like the project and thanks for testing the PR!

I'm afraid to inform that for Android support I'll either need a sponsor or someone else to contribute to the project 😅