Document why using Arkana in a Build Phase Run Script is discouraged

[rogerluan]

Relates to #17

[alobaili]

Hello @rogerluan,

I've been looking at #17 and wondered… would it be possible to add a build phase to check that Arkana has been run manually at least once, otherwise trigger a build failure with a message prompting the developer to run Arkana first?

Something similar to what CocoaPods do when it detects an inconsistent or missing Podfile.lock and triggers a build failure for the developer to run pod install first?

If a build phase like this is possible, I think it would fit as part of the documentation about using Arkana as a build phase.

[rogerluan]

Hi @alobaili 👋 yes, that's possible!
There are two ways we could go about this... One would be a simple weak check like do arkana-related files exist at path X? true/false, and another would be something a lot closer to cocoapods' Podfile.lock checksum. I never created an issue related to this for a future improvement but it's something that I had thought about earlier, and I'll explain it briefly below. It could work like this:

• When running arkana, it'd generate a file e.g. arkana.lock which would contain a hash of the arkana config file that was used when running arkana. This file should be tracked in git.
• In a Run Script we'd add a step that checks whether the config file hash matches the hash in the arkana.lock file.

This would guarantee that if you've never run arkana before, or if the config file changed since your last run, you'd have to run again.

However, it could create a false expectation that it would have to be triggered when an env var (.env or an actual env var) changed, and that won't be the case. We won't be able to tell if an env var changed, in this workflow. Because of this, I've never pursued this initiative, but I'm open to hearing alternative solutions to solve all these 3 problems (never run, config has changed, env var values have changed).

---

If you're seeking solely the "never run" scenario, you could add a Run Script like:

if [ ! -f "$SRCROOT/dependencies/ArkanaKeys/Sources/ArkanaKeys.swift" ]; then
  # print error to STDERR
  echo "error: ArkanaKeys has never been run. Please run 'bundle exec arkana [your options here]' and try again." >&2
  exit 1
fi

[rogerluan]

@alobaili did the solution above solve your issue?

[alobaili]

@rogerluan I haven't used Arkana yet. I was actually evaluating migrating from CocoaPods Keys to Arkana when I wrote my original comment and discussing using it with my team. It may take some time before I use it. Your comment also opened my mind to the other two use cases that the run script doesn't cover.

Once I give it a try I will share my experience.

[rogerluan]

@alobaili ah, got it! Just wondering, could you remind me of how CocoaPods Keys handles those scenarios, or, alternatively, how you and/or your team consumes CocoaPods Keys so that these limitations we just discussed aren't a problem in CocoaPods Keys? 🙏

[alobaili]

I'm not sure about the technical details, but When a developer joins a project he clones the repo and installs CocoaPods and Cocoapods Keys.

The first pod install promts the user to enter the values for the preconfigured keys.

Each time the keys are chaged by the developer and a build is attempted, a build error occurs asking the developer to run pod install again because the .lock file changed.

Each developer is responsible for entering the correct keys and running pod install in his own machine.

The main reason why I looked at Arkana is that i was looking for a solution that is supported by SwiftPM.

[rogerluan]

Got it. By your description and what I remember of CocoaPods Keys, if a developer changes the env var value (not add/remove/rename keys, but simply change the value of an existing key), then no one is informed (Podfile.lock is not updated), and the rest of the team will remain unaware of those changes if the given developer doesn't let them know and ask them nicely to update the env var values in their machines...

Arkana will not only add support to SPM for you, but it will also allow you to share a secret .env file with the team (using any type of mechanism you want to share the .env file, e.g. a password manager, a dotenv file manager, etc), which will help onboard new members significantly 😊

With that being said, the script snippet I sent you earlier should help solve the specific pain problem you pointed, but wouldn't solve for this one:

Each time the keys are chaged by the developer and a build is attempted, a build error occurs asking the developer to run pod install again because the .lock file changed.

To solve for this, a new feature will need to be implemented like the one I mentioned earlier 🙇

I will think about ways to implement this and will keep you posted. But don't expect a timeline as I only work on this project during rare spare time (for the time being) 🙏

Any input/feedback/ideas/suggestions are more than welcome! Let me know if your team ends up adopting Arkana and if there are any trouble integrating it. 💪

[rogerluan]

I created a separate issue to keep track of this new feature #20 🙏

[alobaili]

Thank you @rogerluan I really appreciate your time in this discussion. I hope it will lead to a creative solution to these problems.
I'm sure it would be great to find a way to track when values for keys are changed and to insure they are in sync with the rest of the team.
I believe the existing behavior in CocoaPods Keys affects the locally saved values only.
For example, if a developer uses pod keys set [KEY_NAME] [Secret] then the build error would occur asking the developer to run pod install. As you said, I don't think this communicates to the rest of the team that something changed and they as well have to run pod install or change the locally saved values on their machines.

I'm looking forward for a future where this particular problem finds a suitable solution in Arkana. And please do take all the time needed.

Thanks again.